From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 06:59:04 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E5F237B401; Fri, 11 Apr 2003 06:59:04 -0700 (PDT) Received: from goliat.adm.luth.se (goliat.adm.luth.se [130.240.127.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC3AB43F85; Fri, 11 Apr 2003 06:59:01 -0700 (PDT) (envelope-from pantzer@ludd.luth.se) Received: from ludd.luth.se (pantzer@ra.dc.luth.se [130.240.112.180]) by goliat.adm.luth.se (8.10.1/8.10.1) with ESMTP id h3BDwtv14535; Fri, 11 Apr 2003 15:58:56 +0200 (MET DST) Message-ID: <3E96CA1F.4070000@ludd.luth.se> Date: Fri, 11 Apr 2003 15:58:55 +0200 From: Mattias Pantzare User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Terry Lambert References: <20030410171640.C44793B2@porter.dc.luth.se> <3E95E446.73B7E510@mindspring.com> <3E95E8E9.3080102@ludd.luth.se> <3E95F03C.2A01561D@mindspring.com> In-Reply-To: <3E95F03C.2A01561D@mindspring.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: "Jin Guojun \[DSD\]" cc: Eric Anderson cc: David Gilbert Subject: Re: tcp_output starving -- is due to mbuf get delay? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2003 13:59:04 -0000 Terry Lambert wrote: > Mattias Pantzare wrote: > >>>The products that Jeffrey Hsu and I and Alfred and Jon Mini >>>worked on at a previous company had no problems at all on a >>>1Gbit/S saturating the link, even through a VLAN trunk through >>>Cisco and one other less intelligent switch (i.e. two switches >>>and a VLAN trunk). >> >>A key factor here is that the testst where on a link with a 20ms >>round-tip time, and using a singel TCP connection. So the switches >>where in addition to a few routers on a 10Gbit/s network. > > > Sorry, but tis is not a factor. If you think it is, then you > are running with badly tuned send and receive maximum window > sizes. > > Latency = pool retention time = queue size Then explain this, FreeBSD to FreeBSD on that link uses all CPU on the sender, the reciver is fine, but performance is not. NetBSD to FreeBSD fills the link (1 Gbit/s). On the same computers. MTU 4470. Send and receive maximum windows where tuned to the same values on NetBSD and FreeBSD. And packet loss will affect the performance diffrently if you have a large bandwith-latency product.