On Fri, Jan 12, 2007 at 05:51:18PM +0800, Sepherosa Ziehau wrote: > On 1/12/07, Joe Talbott <[EMAIL PROTECTED]> wrote: > >On Tue, Jan 09, 2007 at 10:39:18PM +0000, Thomas E. Spanjaard wrote: > >> Joe Talbott wrote: > >> >I'm experiencing some slight packet loss on the re0 interface. > >> > > >> >500 packets transmitted, 492 packets received, 1% packet loss > >> >round-trip min/avg/max/stddev = 13.094/17.556/989.262/54.944 ms > >> > > >> >I ran a second ping test from another DragonFlyBSD machine on the same > >> >switch. Both pings were to the same google server. I'm sure this > >> >will be hard to diagnose. Please let me know if there is anything I > >> >can do to glean more information. > >> > >> Pinging outside your LAN introduces so many other variables that the > >> results can't be used to point to re(4); please test only on your LAN to > >> eliminate most of the other variables. E.g., use ttcp or iperf to test > >> performance/loss. > > > >I couldn't get ttcp or iperf on the LAN only to exhibit this problem. > > > >From a discussion on one of the FreeBSD mailing lists this seems to be > >an issue with re(4) TX checksum hardware offloading. > > Interesting, I didn't have this problem on my 8169S(PCI) and it seems > to only plague PCIe devices. Can you help me to do a test? > > on non-re(4) side: > tcpdump -nv -i <ifcace> > > on your re(4) side: > ping -n -c 1 -s 1512 <other-side> > ping -n -c 10 -s 33 <other-side> > > Give me the output of the tcpdump. Thanks
The first time I ran the first ping command it took several tens of seconds to finish and dropped the packet. After the first attempt subsequent: ping -n -c 1 -s 1512 <other-side> worked fine. The problem I see is intermittent though so that may not mean much. I can also do: ifconfig re0 down ifconfig re0 up and the next: ping -n -c 1 -s 1512 <other-side> fails again. Tcpdump output mailed privately. Thanks, Joe
