From: Denys Fedoryshchenko <denys@visp.net.lb>
To: Ingo Molnar <mingo@elte.hu>
Cc: "Kok, Auke" <auke-jan.h.kok@intel.com>,
David Miller <davem@davemloft.net>,
vgusev@openvz.org, 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, xemul@openvz.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [E1000-devel] [TCP]: TCP_DEFER_ACCEPT causes leak sockets
Date: Thu, 19 Jun 2008 00:41:52 +0300 [thread overview]
Message-ID: <200806190041.52532.denys@visp.net.lb> (raw)
In-Reply-To: <20080618213230.GA17821@elte.hu>
> * 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
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
--
------
Technical Manager
Virtual ISP S.A.L.
Lebanon
WARNING: multiple messages have this Message-ID (diff)
From: Denys Fedoryshchenko <denys@visp.net.lb>
To: Ingo Molnar <mingo@elte.hu>
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:41:52 +0300 [thread overview]
Message-ID: <200806190041.52532.denys@visp.net.lb> (raw)
In-Reply-To: <20080618213230.GA17821@elte.hu>
> * 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
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
--
------
Technical Manager
Virtual ISP S.A.L.
Lebanon
-------------------------------------------------------------------------
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 21:41 UTC|newest]
Thread overview: 41+ 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:09 ` Ingo Molnar
2008-06-17 8:32 ` 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:27 ` Ingo Molnar
2008-06-17 9:29 ` David Miller
2008-06-17 9:39 ` Ingo Molnar
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 20:08 ` Ingo Molnar
2008-06-18 21:25 ` [E1000-devel] " Kok, Auke
2008-06-18 22:12 ` David Miller
2008-06-18 22:12 ` David Miller
2008-06-19 7:06 ` Jarek Poplawski
2008-06-19 7:06 ` Jarek Poplawski
2008-06-18 21:32 ` [E1000-devel] " Ingo Molnar
2008-06-18 21:32 ` Ingo Molnar
2008-06-18 21:41 ` Denys Fedoryshchenko [this message]
2008-06-18 21:41 ` Denys Fedoryshchenko
2008-06-18 22:05 ` [E1000-devel] " Ingo Molnar
2008-06-18 22:05 ` Ingo Molnar
2008-06-18 22:44 ` [E1000-devel] " Denys Fedoryshchenko
2008-06-18 22:44 ` Denys Fedoryshchenko
2008-06-18 23:14 ` [E1000-devel] " Ingo Molnar
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=200806190041.52532.denys@visp.net.lb \
--to=denys@visp.net.lb \
--cc=auke-jan.h.kok@intel.com \
--cc=davem@davemloft.net \
--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=mingo@elte.hu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.