Date: Fri, 11 Apr 2003 15:58:55 +0200 From: Mattias Pantzare <pantzer@ludd.luth.se> To: Terry Lambert <tlambert2@mindspring.com> Cc: David Gilbert <dgilbert@velocet.ca> Subject: Re: tcp_output starving -- is due to mbuf get delay? Message-ID: <3E96CA1F.4070000@ludd.luth.se> In-Reply-To: <3E95F03C.2A01561D@mindspring.com> References: <20030410171640.C44793B2@porter.dc.luth.se> <3E95E446.73B7E510@mindspring.com> <3E95E8E9.3080102@ludd.luth.se> <3E95F03C.2A01561D@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E96CA1F.4070000>