Date: Tue, 16 Jan 2007 22:40:17 +0100 From: Jon Otterholm <jon.otterholm@ide.resurscentrum.se> To: freebsd-net@freebsd.org Subject: Re: Lenovo X60 em Message-ID: <45AD4641.2050300@ide.resurscentrum.se> In-Reply-To: <2a41acea0701161323y2c729e4ew4c61b8f4418f6058@mail.gmail.com> References: <45ACF404.20700@ide.resurscentrum.se> <2a41acea0701160958m27c3537ctb25e5420e7a46891@mail.gmail.com> <45AD3C2E.6010806@ide.resurscentrum.se> <2a41acea0701161323y2c729e4ew4c61b8f4418f6058@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jack Vogel wrote: > On 1/16/07, Jon Otterholm <jon.otterholm@ide.resurscentrum.se> wrote: >> Jack Vogel wrote: >> > On 1/16/07, Jon Otterholm <jon.otterholm@ide.resurscentrum.se> wrote: >> >> Hi. >> >> >> >> I have trouble with high latency on my new X60 with em-interface. >> Anyone >> >> else with the same problem? I´m running 6.2-RELEASE. >> > >> > Would you please give a bit more detail. >> > >> > Jack >> Here comes some info: >> >> uname -a >> FreeBSD onob2.domain.local 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan >> 12 11:05:30 UTC 2007 >> root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386 >> >> $ ifconfig em0 >> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 >> options=b<RXCSUM,TXCSUM,VLAN_MTU> >> inet 192.168.98.98 netmask 0xffffff00 broadcast 192.168.98.255 >> ether 00:16:d3:35:0a:a9 >> media: Ethernet autoselect (100baseTX <full-duplex>) >> status: active >> >> dmesg >> em0: <Intel(R) PRO/1000 Network Connection Version - 6.2.9> port >> 0x2000-0x201f mem 0xee000000-0xee01ffff irq 16 at device 0.0 on pci2 >> em0: Ethernet address: 00:16:d3:35:0a:a9 >> >> pciconf -l >> em0@pci2:0:0: class=0x020000 card=0x207e17aa chip=0x109a8086 rev=0x00 >> hdr=0x00 >> >> I think I found a pattern to work with. If I do a echo-reply wit the >> "-D" (no fragment) and increase the packet size (-s) to 1472 I get >> normal response times: >> >> onob2# ping -D -s 1470 www.sunet.se >> PING www.sunet.se (192.36.125.18): 1470 data bytes >> 1478 bytes from 192.36.125.18: icmp_seq=0 ttl=57 time=47.770 ms >> 1478 bytes from 192.36.125.18: icmp_seq=1 ttl=57 time=46.128 ms >> 1478 bytes from 192.36.125.18: icmp_seq=2 ttl=57 time=47.038 ms >> 1478 bytes from 192.36.125.18: icmp_seq=3 ttl=57 time=46.457 ms >> 1478 bytes from 192.36.125.18: icmp_seq=4 ttl=57 time=46.375 ms >> 1478 bytes from 192.36.125.18: icmp_seq=5 ttl=57 time=46.291 ms >> 1478 bytes from 192.36.125.18: icmp_seq=6 ttl=57 time=46.707 ms >> 1478 bytes from 192.36.125.18: icmp_seq=7 ttl=57 time=46.623 ms >> 1478 bytes from 192.36.125.18: icmp_seq=8 ttl=57 time=47.541 ms >> 1478 bytes from 192.36.125.18: icmp_seq=9 ttl=57 time=46.458 ms >> >> But when decreasing packet size: >> >> onob2# ping -D -s 64 www.sunet.se >> PING www.sunet.se (192.36.125.18): 64 data bytes >> 72 bytes from 192.36.125.18: icmp_seq=0 ttl=57 time=102.082 ms >> 72 bytes from 192.36.125.18: icmp_seq=1 ttl=57 time=897.502 ms >> 72 bytes from 192.36.125.18: icmp_seq=2 ttl=57 time=896.420 ms >> 72 bytes from 192.36.125.18: icmp_seq=3 ttl=57 time=27.858 ms >> 72 bytes from 192.36.125.18: icmp_seq=4 ttl=57 time=894.255 ms >> 72 bytes from 192.36.125.18: icmp_seq=5 ttl=57 time=893.245 ms >> 72 bytes from 192.36.125.18: icmp_seq=6 ttl=57 time=892.244 ms >> 72 bytes from 192.36.125.18: icmp_seq=7 ttl=57 time=891.502 ms >> 72 bytes from 192.36.125.18: icmp_seq=8 ttl=57 time=890.421 ms >> 72 bytes from 192.36.125.18: icmp_seq=9 ttl=57 time=785.403 ms >> >> After some time (~1h) all ICMP seems to work, but when using tcp it >> doesn't work. For example I tried a "pkg_add -r bash2" and it timed out. >> I haven't had time to make any dumps on traffic, I would appreciate some >> hints on how to approach this to get some useful output. >> >> BTW: "netstat -i" shows no i/o-error. > > Any chance of testing at gig speed, or are you connected to some > 10/100 switch? I will try on a gig-switch tomorrow. > This site you are pinging, how are you connected to > it? It is a site on the internet but I get the same results when testing on the same subnet. > > This is odd though, no doubt, did this problem not exist in previous > releases, or is this a new setup? New setup. I Have not tried any other release. Should I try with Intel's own driver? //Jon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45AD4641.2050300>