From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 04:29:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5745106566B for ; Tue, 12 Jan 2010 04:29:58 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by mx1.freebsd.org (Postfix) with ESMTP id 869E68FC12 for ; Tue, 12 Jan 2010 04:29:58 +0000 (UTC) Received: from [10.0.0.171] (unknown [64.9.237.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 67F7322E1EB; Mon, 11 Jan 2010 23:29:39 -0500 (EST) Message-ID: <4B4BFAA7.8030103@gmail.com> Date: Mon, 11 Jan 2010 20:29:27 -0800 From: David Ehrmann User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pyunyh@gmail.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> In-Reply-To: <20100112024900.GG1228@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 04:29:58 -0000 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.