Date: Mon, 11 Jan 2010 20:29:27 -0800 From: David Ehrmann <ehrmann@gmail.com> To: pyunyh@gmail.com Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem Message-ID: <4B4BFAA7.8030103@gmail.com> In-Reply-To: <20100112024900.GG1228@michelle.cdnetworks.com> References: <4B40AFFA.6090706@gmail.com> <20100103221630.GV1166@michelle.cdnetworks.com> <4B47B4F6.8030106@gmail.com> <20100109013145.GG18529@michelle.cdnetworks.com> <4B4ACD68.5030907@gmail.com> <20100111203557.GB1228@michelle.cdnetworks.com> <4B4BB679.2060500@gmail.com> <20100112000859.GD1228@michelle.cdnetworks.com> <4B4BCEE9.1060600@gmail.com> <20100112024900.GG1228@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Pyun YongHyeon wrote: > It seems iperf on FreeBSD was broken. It incorrectly generates > huge-packet with IP length 0 so other host disconnected the > TCP connection. Not sure it could be related with threading though. > Use netperf instead, it would be more reliable than iperf. > I saw a lot of warnings when I opened the cap file in Wireshark about the length in the IP header being wrong. I'll start looking into netperf > It's normal see some dropped frames under high network load. And > you can't compare gigabit controller to fast ethernet controller. > Very true, and that's why I tried a lower load. I was a little surprised to see it choking at just 1 Mb/s (that's bits, not bytes), though. > I have exact the same revision of the hardware and I don't have > encountered your issue here. Instead of measuring performance > number with broken iperf, check whether you still get > "Connection reset by peer" message with csup(1) when you use vge(4) > interface. If you still see the message, please send me tcpdump > capture in private. > csup is still working. I actually think I *might* have the problem solved. Switching the mount from UDP (why it was the default for NFS in this Linux distro, I don't know) to TCP seems to have fixed it. My guess is that some sort of race condition occurred or there's a bug in someone's NFS flow control mechanism. A 10x CPU and network performance difference must be more than is usually tested. I hope. I'll keep testing NFS over TCP and see if it fixed my problem.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B4BFAA7.8030103>