netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gundersen <gundy@iinet.net.au>
To: netdev@vger.kernel.org
Subject: Re: Realtek r8168 slow outbound transfer -  potential fix/workaround
Date: Fri, 15 Jun 2007 00:57:45 +1000	[thread overview]
Message-ID: <46715769.9060101@iinet.net.au> (raw)
In-Reply-To: <20070613231124.GC22521@electric-eye.fr.zoreil.com>


> What is the value of the MTU for your 8168 device ?

Hi Francois,

The MTU for the adapter is set at the default of 1500.

A bit more background on how I came across this might be in order.  I 
noticed it when performing very simple SQL queries against a postgres 
database on my server.  I captured the traffic on an XP client machine 
using wireshark and on the linux server with tcpdump. I noticed that 
although the linux server claimed to have sent 2 reply packets, XP was 
seeing only the first.

What got me thinking was the fact that the time between the first and 
second response packets from postgres was 0.000005 seconds (according to 
the tcpdump timestamps).  Another 0.4 seconds after that a retry was 
attempted and the packet managed to make it though to the windows 
client.  I started wondering if there might be something going on with 
tightly spaced packets and that's how I ended up checking the NPQ flag. 
  (I also looked into increasing the default interframe gap between 
packets, but that didn't seem to help).

I'm happy to help with additional information including the packet 
captures if you'd like to take a look.

Also, I realised after I posted that first message that having a minimum 
udelay of 25us in that delay loop was probably a bit foolish.  I guess I 
was just so happy to have found something that worked for me that I 
needed to get it off my chest before thinking it through fully.  The 
udelay(25) ends up increasing the minimum inter-frame gap way beyond 
what should be reasonable.    I haven't had a good chance to test this 
yet, but I tried dropping the udelay(25) and using ndelay(10) instead 
and it appeared to load the cpu less that way.


Regards,
Dave.

  reply	other threads:[~2007-06-14 14:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-13 14:46 Realtek r8168 slow outbound transfer - potential fix/workaround David Gundersen
2007-06-13 23:11 ` Francois Romieu
2007-06-14 14:57   ` David Gundersen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-08-13 18:53 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46715769.9060101@iinet.net.au \
    --to=gundy@iinet.net.au \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).