lkml.org 
[lkml]   [2008]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [E1000-devel] [TCP]: TCP_DEFER_ACCEPT causes leak sockets
Date
> * 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


\
 
 \ /
  Last update: 2008-06-18 23:45    [W:0.086 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site