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.
next prev parent 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).