netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: Realtek r8168 slow outbound transfer - potential fix/workaround
@ 2007-08-13 18:53 Bruce Cole
  2007-08-14 21:19 ` Francois Romieu
  0 siblings, 1 reply; 7+ messages in thread
From: Bruce Cole @ 2007-08-13 18:53 UTC (permalink / raw)
  To: netdev; +Cc: bacole

David Gundersen <gundy@iinet.net.au> :
 > Now, on to my workaround. Putting a spin style wait like the following
 > in front of the line above seemed to solve the problem for me:
 >
 >
 > if (RTL_R8(TxPoll) & NPQ) {
 >      for (i = 20; i > 0; i--) {
 >       if (!(RTL_R8(TxPoll) & NPQ))
 >        break;
 >       udelay(25);
 >     }
 > }
 >
 > ...
 >
 > RTL_W8(TxPoll, NPQ);

What's the status of this fix?  It (or something more refined) seems 
necessary
to correct the current performance problems with this driver.  Some
background:

I just got a motherboard (gigabyte ga-p35-ds3p) which has built-in ethernet
via the realtek rtl8111b chip.  I've been experiencing serious performance
problems when it comes to transmitting files across the network using samba.
By serious I mean throughput is probably 200X slower than it should be.  
This
is the same problem reported by several others.  Some references:

"[Samba] Miserable read performance":
http://lists.samba.org/archive/samba/2007-July/133553.html
"[Samba] RE: Samba running slow"
http://lists.samba.org/archive/samba/2007-January/128846.html
"Re: Realtek RTL8111B serious performance issues"
http://www.mail-archive.com/netdev@vger.kernel.org/msg42860.html

I started with the stock 2.6.22.1 driver, then I tried the
20070628-2.6.22-rc6-r8169-test.patch on top of it, which made no difference.
Then I tried David Gundersen's spin-wait patch and performance was fixed!

Oddly enough, I don't see this performance problem when I test transmit
performance using ttcp, or even when I transfer files with scp.  It 
seems the
extra application layer latency of something like samba is necessary to
reproduce the problem.

I can troubleshoot in more detail if that would help get a proper fix
developed.


^ permalink raw reply	[flat|nested] 7+ messages in thread
[parent not found: <25536.1187071305@iinet.net.au>]
* Realtek r8168 slow outbound transfer -  potential fix/workaround
@ 2007-06-13 14:46 David Gundersen
  2007-06-13 23:11 ` Francois Romieu
  0 siblings, 1 reply; 7+ messages in thread
From: David Gundersen @ 2007-06-13 14:46 UTC (permalink / raw)
  To: netdev


Hi all,

I've been doing a bit of investigation work into a problem that I've 
been experiencing with the latest available r8168 driver from realtek 
('r8168-8.001.00') & linux kernel 2.6.21.1.

I have been experiencing wierd problems with slow outbound traffic that 
seem to go away if there's traffic coming into the device.  Googling 
seen reports of this in a number of places on the web so I get the 
feeling I'm not alone.

I decided to spend a few hours looking into this and as best I could 
tell it's because back-to-back outbound packets result in the 2nd packet 
being mysteriously dropped.

What I found was that line 2505:

  RTL_W8(TxPoll, NPQ);

in the rtl8168_start_xmit() handler is the part that's telling the NIC 
to kick off the next transfer.

I'm guessing that the signal must be edge triggered because after a few 
checks I noticed that during times of heavy transmission, it was 
possible for the card to still have this bit set from the previous 
packet's transmission request, with the result being that the command to 
kick off the next packets' transmission would be lost. The net effect of 
this was that timeouts & retransmits were occurring further up the 
protocol stack, and I believe that was what was responsible for the 
terrible performance.

Now, on to my workaround. Putting a spin style wait like the following 
in front of the line above seemed to solve the problem for me:


if (RTL_R8(TxPoll) & NPQ) {
     for (i = 20; i > 0; i--) {
      if (!(RTL_R8(TxPoll) & NPQ))
       break;
      udelay(25);
    }
}

...

RTL_W8(TxPoll, NPQ);

This waits for the card to signal that it's dealt with the previous 
packet before telling it to process the next. YMMV.

It would be interesting to hear if other people have similar success 
with the above workaround.  Also, I'm not convinced that having a spin 
style wait is the best solution here - if anybody else is able to offer 
a better solution it'd be great to hear it.


Kind Regards,

Dave.

^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-08-15  7:21 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-13 18:53 Realtek r8168 slow outbound transfer - potential fix/workaround Bruce Cole
2007-08-14 21:19 ` Francois Romieu
2007-08-15  7:17   ` Bruce Cole
     [not found] <25536.1187071305@iinet.net.au>
2007-08-15  5:46 ` Bruce Cole
  -- strict thread matches above, loose matches on Subject: below --
2007-06-13 14:46 David Gundersen
2007-06-13 23:11 ` Francois Romieu
2007-06-14 14:57   ` David Gundersen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).