r8169: slow samba performance
Subsystems (2)
Quoted 9 lines
Just upgraded a motherboard and it came with an onboard
Realtek card which appears to use the r8169 driver. The
machine is a samba server and when serving files to a local
Linux or Windows client, I only get approx 40-60 kbps. Write performance is fine though, in the tens of mbps and scp, nfs, and ftp server all work well so it appears
specific to the Samba load. However, when serving to more
than one client symoltaniously, performance goes up
dramatically, again into the tens of mbps or when there is
other network activity.
Shane, join the crowd :) Try the fix I just re-posted over here:
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Shane
Quoted 2 lines · Bruce Cole
Shane, join the crowd :) Try the fix I just re-posted over here:
Quoted 7 lines
Bruce, gigabit speeds thanks for the pointer. This fix works well for me though I just added the three or so lines in the elseif statement as it rejected with the r8169-20070818. I suppose I could've merged the whole thing and if you need that tested, let me know but this is looking good.
Glad it works for you. I'm not the maintainer, and also don't have adequate specs from Realtek to definitively explain why the NPQ bit apparently needs to be re-enabled when some but not all of the TX FIFO is dequeued. It is documented as if it isn't cleared until the FIFO is empty. So I assume an official patch will have to wait until Francois is back.
Quoted 6 lines · Bruce Cole
Quoted 5 lines · Shane
Quoted 2 lines · Bruce Cole
Shane, join the crowd :) Try the fix I just re-posted over here:
Quoted 8 lines
Quoted 7 lines
Bruce, gigabit speeds thanks for the pointer. This fix works well for me though I just added the three or so lines in the elseif statement as it rejected with the r8169-20070818. I suppose I could've merged the whole thing and if you need that tested, let me know but this is looking good.
Glad it works for you. I'm not the maintainer, and also don't have adequate specs from Realtek to definitively explain why the NPQ bit apparently needs to be re-enabled when some but not all of the TX FIFO is dequeued. It is documented as if it isn't cleared until the FIFO is empty. So I assume an official patch will have to wait until Francois is back.
I have had abysmal performance trying to remotely run X apps via ssh on a computer with a RTL8111 NIC. Saw this message and decided to give this patch a try --- success! Much, much better.
Thanks,
John
[email protected] <[email protected]> :
[...]
Quoted 3 lines
I have had abysmal performance trying to remotely run X apps via ssh on a computer with a RTL8111 NIC. Saw this message and decided to give this patch a try --- success! Much, much better.
Can you give a try to:
http://www.fr.zoreil.com/people/francois/misc/20070903-2.6.23-rc5-r8169-test.patch
or just patches #0001 + #0002 at:
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.23-rc5/r8169-20070903/
Signature · 1 line
Ueimor
Quoted 6 lines · Francois Romieu
[email protected] <[email protected]> :
[...]Quoted 3 lines
I have had abysmal performance trying to remotely run X apps via ssh on a computer with a RTL8111 NIC. Saw this message and decided to give this patch a try --- success! Much, much better.
Quoted 7 lines
Can you give a try to:
http://www.fr.zoreil.com/people/francois/misc/20070903-2.6.23-rc5-r8169-test.patch
or just patches #0001 + #0002 at:
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.23-rc5/r8169-20070903/
20070903-2.6.23-rc5-r8169-test.patch applied against 2.6.23-rc5 works fine. Performance is acceptable.
Would you like me to *just* try patches 1 & 2, to help narrow down anything?
Thanks,
John
[email protected] <[email protected]> :
[...]
Quoted 2 lines
20070903-2.6.23-rc5-r8169-test.patch applied against 2.6.23-rc5 works fine. Performance is acceptable.
Does "acceptable" mean that there is a noticeable difference when compared to the patch based on a busy-waiting loop ?
Quoted 1 line
Would you like me to *just* try patches 1 & 2, to help narrow down anything?
I expect patch #2 alone to be enough to enhance the performance. If it gets proven, the patch would be a good candidate for a quick merge upstream.
Signature · 1 line
Ueimor
Quoted 7 lines · Francois Romieu
[email protected] <[email protected]> :
[...]Quoted 2 lines
20070903-2.6.23-rc5-r8169-test.patch applied against 2.6.23-rc5 works fine. Performance is acceptable.
Does "acceptable" mean that there is a noticeable difference when compared to the patch based on a busy-waiting loop ?
Without this patch, latency in bringing up emacs, or in display of pages in firefox is extremely high. With the patch, latency is pretty much what I see when using an old tulip based NIC.
Is there a specific test you wish me to try?
Quoted 4 lines
Quoted 1 line
Would you like me to *just* try patches 1 & 2, to help narrow down anything?
I expect patch #2 alone to be enough to enhance the performance. If it gets proven, the patch would be a good candidate for a quick merge upstream.
Okay, I will build another kernel with just #2 applied.
John
Quoted 11 lines · Francois Romieu
Does "acceptable" mean that there is a noticeable difference when compared to the patch based on a busy-waiting loop ?
Quoted 2 lines
Would you like me to *just* try patches 1 & 2, to help narrow down anything?
I expect patch #2 alone to be enough to enhance the performance. If it gets proven, the patch would be a good candidate for a quick merge upstream.
Patch #0002 looks functionally equivalent to the patch I already pointed folks to and which I showed as being sufficient to address the TX queue problem. The fix has also already been confirmed by shane, that fix being:
diff -c r/r8169.c r3/r8169-out.c
*** r/r8169.c 2007-08-18 11:54:58.000000000 -0700
--- r3/r8169-out.c 2007-09-04 14:23:49.000000000 -0700
***************
*** 2646,2651 ****
--- 2646,2655 ----
if (netif_queue_stopped(dev) &&
(TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)) {
netif_wake_queue(dev);
+ } else if (dirty_tx != tp->cur_tx) {
+ netif_tx_lock(dev);
+ RTL_W8(TxPoll, NPQ);
+ netif_tx_unlock(dev);
}
}}
In any case, I've tried your latest version of the patch, 0002-r8169-workaround-against-ignored-TxPoll-writes-8168.patch, and it alone works as well.
I'm not sure why you describe this as being an "8168 hack", given that the problem has been seen with the 8111b chip (I have an 8111b chip on my gigabyte motherboard).
Now since this change heals the TX queue stall, it would seem that the real underlying problem involves a race condition with enqueueing to the TX queue while the controller is processing the queue. The ultimate fix for that I bet is either to address locking at TX enqueue time, or there is a controller bug. Any clarification from realtek on the necessary processing for the NPQ bit, or a known controller problem?
PS: I've also received private email that this problem pertains to video streaming (to a Kiss DVD player) not just samba or X11 traffic. Basically most all high-level TCP based protocols are affected it seems. This serious performance problem should be considered to impact a lot more than just samba users.