| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <200806190041.52532.denys@visp.net.lb> Date: Thu, 19 Jun 2008 00:41:52 +0300 From: Denys Fedoryshchenko <denys@...p.net.lb> To: Ingo Molnar <mingo@...e.hu> Cc: "Kok, Auke" <auke-jan.h.kok@...el.com>, David Miller <davem@...emloft.net>, vgusev@...nvz.org, e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, rjw@...k.pl, mcmanus@...ksong.com, ilpo.jarvinen@...sinki.fi, kuznet@....inr.ac.ru, xemul@...nvz.org, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [E1000-devel] [TCP]: TCP_DEFER_ACCEPT causes leak sockets > * Ingo Molnar <mingo@...e.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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists