From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 02:57:13 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 245BD1065696 for ; Tue, 12 Jan 2010 02:57:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by mx1.freebsd.org (Postfix) with ESMTP id C37208FC19 for ; Tue, 12 Jan 2010 02:57:12 +0000 (UTC) Received: by qyk41 with SMTP id 41so10714288qyk.29 for ; Mon, 11 Jan 2010 18:57:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=rh/psri3aaeld9tgeXmEc2NMIknQdAZRjd9WzTYEo5Q=; b=IwwGl6WEOYUIZiVYlKsUDMmCFuds/mjn7rjyOrTnF8GG7jJK3yz6P4hKnJcUtS/1OF N7IZYW+6fWPb5I+o0Ya7TDt31uDwOsdiFYVy8MG5rD1W6Q5ow3ZAVXlSusbDznXZpe1Q WN6Fd5xLZFKPDPCXW7OkxL5U33t7SaWDjmsd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=kKcuvH7sqQozT0Kom6orP1jkCFCJt88zYnVLE+zJOLDqpMCMY2wXtrlVCmRFm53WWe PKoKKwa5To5RDzYsaLspSSqsn6dOt7ecO+lTbu/cgJneHbC0f4yKiI/4KXAwZgEkADII up8gS4QjoEn12Fb5+oXyHTpp03tz7iH0xPVkM= Received: by 10.224.79.229 with SMTP id q37mr750972qak.2.1263265032020; Mon, 11 Jan 2010 18:57:12 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 21sm5192553qyk.0.2010.01.11.18.57.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Jan 2010 18:57:11 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 11 Jan 2010 18:56:29 -0800 From: Pyun YongHyeon Date: Mon, 11 Jan 2010 18:56:29 -0800 To: David Ehrmann Message-ID: <20100112025629.GH1228@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100112024900.GG1228@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com 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 02:57:13 -0000 On Mon, Jan 11, 2010 at 06:49:00PM -0800, Pyun YongHyeon wrote: > On Mon, Jan 11, 2010 at 05:22:49PM -0800, David Ehrmann wrote: [...] > > I did this one between two similar FreeBSD systems (8.0 and 8.0 RC1, I > > think). There wasn't an error in netstat -s on the receiver, but I ran > > tcpdump, anyway. The checksums were good, but iperf ended with "read > > failed: connection refused." On the non-vge box, once the vge box is > > done sending, it sends four identical UDP packets to the vge host, I > > think to ask it for sending statistics. Instead of statistics, it got > > back an ICMP packet saying "port unreachable." This happens with a > > freebsd client, but not a linux client (I didn't confirm the ICMP > > message with tcpdump, though). All iperf versions are the same (2.0.4), > > but the linux one doesn't have any threading (which shouldn't be an > > issue when I'm not using that option). > > 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. > Disabling threading make iperf work again. And don't be surprised at the dropped counter of iperf, it's normal for UDP frames. Good hardware and fast system may have better numbers but you can't completely remove dropped counters.