From: Ingo Molnar <mingo@elte.hu>
To: Denys Fedoryshchenko <denys@visp.net.lb>
Cc: vgusev@openvz.org, "Kok, Auke" <auke-jan.h.kok@intel.com>,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, rjw@sisk.pl, mcmanus@ducksong.com,
ilpo.jarvinen@helsinki.fi, kuznet@ms2.inr.ac.ru,
Linus Torvalds <torvalds@linux-foundation.org>,
David Miller <davem@davemloft.net>,
xemul@openvz.org
Subject: Re: [TCP]: TCP_DEFER_ACCEPT causes leak sockets
Date: Thu, 19 Jun 2008 00:05:27 +0200 [thread overview]
Message-ID: <20080618220527.GA19155@elte.hu> (raw)
In-Reply-To: <200806190041.52532.denys@visp.net.lb>
* Denys Fedoryshchenko <denys@visp.net.lb> wrote:
> > * Ingo Molnar <mingo@elte.hu> wrote:
> > with e1000e i get:
> >
> > 64 bytes from europe (10.0.1.15): icmp_seq=1 ttl=64 time=0.212 ms
> > 64 bytes from europe (10.0.1.15): icmp_seq=2 ttl=64 time=0.372 ms
> > 64 bytes from europe (10.0.1.15): icmp_seq=3 ttl=64 time=0.815 ms
> > 64 bytes from europe (10.0.1.15): icmp_seq=4 ttl=64 time=0.961 ms
> > 64 bytes from europe (10.0.1.15): icmp_seq=5 ttl=64 time=0.201 ms
> > 64 bytes from europe (10.0.1.15): icmp_seq=6 ttl=64 time=0.788 ms
> >
> > TCP latencies are fine too - ssh feels snappy again.
> >
> > it still does not have nearly as good latencies as say forcedeth though:
> >
> > 64 bytes from mercury (10.0.1.13): icmp_seq=1 ttl=64 time=0.076 ms
> > 64 bytes from mercury (10.0.1.13): icmp_seq=2 ttl=64 time=0.085 ms
> > 64 bytes from mercury (10.0.1.13): icmp_seq=3 ttl=64 time=0.045 ms
> > 64 bytes from mercury (10.0.1.13): icmp_seq=4 ttl=64 time=0.053 ms
> >
> > that's 10 times better packet latencies.
> >
> > and even an ancient Realtek RTL-8139 over 10 megabit Ethernet (!) has
> > better latencies than the e1000e over 1000 megabit:
> >
> > 64 bytes from pluto (10.0.1.10): icmp_seq=2 ttl=64 time=0.309 ms
> > 64 bytes from pluto (10.0.1.10): icmp_seq=3 ttl=64 time=0.333 ms
> > 64 bytes from pluto (10.0.1.10): icmp_seq=4 ttl=64 time=0.329 ms
> > 64 bytes from pluto (10.0.1.10): icmp_seq=5 ttl=64 time=0.311 ms
> > 64 bytes from pluto (10.0.1.10): icmp_seq=6 ttl=64 time=0.302 ms
> >
> > is it done intentionally perhaps? I dont think it makes much sense to
> > delay rx/tx processing on a completely idle box for such a long time.
> Idle box, ICH8 chipset, e1000e, latest git.
>
> MegaRouterCore-KARAM ~ # ping 192.168.20.26
> PING 192.168.20.26 (192.168.20.26) 56(84) bytes of data.
> 64 bytes from 192.168.20.26: icmp_seq=1 ttl=64 time=0.109 ms
> 64 bytes from 192.168.20.26: icmp_seq=2 ttl=64 time=0.134 ms
> 64 bytes from 192.168.20.26: icmp_seq=3 ttl=64 time=0.120 ms
> 64 bytes from 192.168.20.26: icmp_seq=4 ttl=64 time=0.117 ms
> 64 bytes from 192.168.20.26: icmp_seq=5 ttl=64 time=0.117 ms
> 64 bytes from 192.168.20.26: icmp_seq=6 ttl=64 time=0.113 ms
ok, that looks much better! i have another box with e1000, ich7:
64 bytes from titan (10.0.1.14): icmp_seq=5 ttl=64 time=0.345 ms
64 bytes from titan (10.0.1.14): icmp_seq=6 ttl=64 time=1.03 ms
64 bytes from titan (10.0.1.14): icmp_seq=7 ttl=64 time=0.383 ms
64 bytes from titan (10.0.1.14): icmp_seq=8 ttl=64 time=0.320 ms
64 bytes from titan (10.0.1.14): icmp_seq=9 ttl=64 time=0.996 ms
64 bytes from titan (10.0.1.14): icmp_seq=10 ttl=64 time=0.248 ms
> Disabling interrupt moderation
> MegaRouterCore-KARAM ~ # ethtool -C eth0 rx-usecs 0
> MegaRouterCore-KARAM ~ # ping 192.168.20.26
> PING 192.168.20.26 (192.168.20.26) 56(84) bytes of data.
> 64 bytes from 192.168.20.26: icmp_seq=1 ttl=64 time=0.072 ms
> 64 bytes from 192.168.20.26: icmp_seq=2 ttl=64 time=0.091 ms
> 64 bytes from 192.168.20.26: icmp_seq=3 ttl=64 time=0.066 ms
> 64 bytes from 192.168.20.26: icmp_seq=4 ttl=64 time=0.065 ms
> 64 bytes from 192.168.20.26: icmp_seq=5 ttl=64 time=0.077 ms
> 64 bytes from 192.168.20.26: icmp_seq=6 ttl=64 time=0.073 ms
>
> Maybe try the same?
> ethtool -C eth0 rx-usecs 0
well i tend not to tweak my drivers with such options because i want to
experience and test what 99.9% of our users will experience in the
field. The reality is that if it's not the default behavior, it's almost
as if it didnt exist at all.
but even with that tune on e1000e (on the t60, ich7) i still get rather
large numbers:
earth4:~/s> ping eu
PING europe (10.0.1.15) 56(84) bytes of data.
64 bytes from europe (10.0.1.15): icmp_seq=1 ttl=64 time=0.250 ms
64 bytes from europe (10.0.1.15): icmp_seq=2 ttl=64 time=0.250 ms
64 bytes from europe (10.0.1.15): icmp_seq=3 ttl=64 time=0.225 ms
64 bytes from europe (10.0.1.15): icmp_seq=4 ttl=64 time=0.932 ms
64 bytes from europe (10.0.1.15): icmp_seq=5 ttl=64 time=0.251 ms
64 bytes from europe (10.0.1.15): icmp_seq=6 ttl=64 time=0.915 ms
64 bytes from europe (10.0.1.15): icmp_seq=7 ttl=64 time=0.250 ms
64 bytes from europe (10.0.1.15): icmp_seq=8 ttl=64 time=0.238 ms
64 bytes from europe (10.0.1.15): icmp_seq=9 ttl=64 time=0.390 ms
64 bytes from europe (10.0.1.15): icmp_seq=10 ttl=64 time=0.260 ms
Ingo
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
next prev parent reply other threads:[~2008-06-18 22:05 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-11 12:58 [TCP]: TCP_DEFER_ACCEPT causes leak sockets Vitaliy Gusev
2008-06-11 13:57 ` Alexey Kuznetsov
2008-06-11 23:52 ` David Miller
2008-06-12 23:32 ` David Miller
2008-06-13 6:30 ` Ingo Molnar
2008-06-13 9:32 ` David Miller
2008-06-13 11:09 ` Ingo Molnar
2008-06-13 11:47 ` Ingo Molnar
2008-06-13 21:10 ` Ingo Molnar
2008-06-16 23:59 ` David Miller
2008-06-17 7:26 ` Ingo Molnar
2008-06-17 7:38 ` David Miller
2008-06-17 8:09 ` Ingo Molnar
2008-06-17 8:32 ` Ingo Molnar
2008-06-17 9:08 ` David Miller
2008-06-17 9:27 ` Ingo Molnar
2008-06-17 9:29 ` David Miller
2008-06-17 9:39 ` Ingo Molnar
2008-06-18 18:50 ` [E1000-devel] " Kok, Auke
2008-06-18 20:08 ` Ingo Molnar
2008-06-18 21:25 ` [E1000-devel] " Kok, Auke
2008-06-18 22:12 ` David Miller
2008-06-19 7:06 ` Jarek Poplawski
2008-06-18 21:32 ` Ingo Molnar
2008-06-18 21:41 ` Denys Fedoryshchenko
2008-06-18 22:05 ` Ingo Molnar [this message]
2008-06-18 22:44 ` Denys Fedoryshchenko
2008-06-18 23:14 ` Ingo Molnar
2008-06-17 8:43 ` Vitaliy Gusev
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=20080618220527.GA19155@elte.hu \
--to=mingo@elte.hu \
--cc=auke-jan.h.kok@intel.com \
--cc=davem@davemloft.net \
--cc=denys@visp.net.lb \
--cc=e1000-devel@lists.sourceforge.net \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mcmanus@ducksong.com \
--cc=netdev@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=torvalds@linux-foundation.org \
--cc=vgusev@openvz.org \
--cc=xemul@openvz.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).