Date: Fri, 11 Apr 2003 09:08:19 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mattias Pantzare <pantzer@ludd.luth.se> Cc: David Gilbert <dgilbert@velocet.ca> Subject: Re: tcp_output starving -- is due to mbuf get delay? Message-ID: <3E96E873.9CC19544@mindspring.com> References: <20030410171640.C44793B2@porter.dc.luth.se> <3E95E446.73B7E510@mindspring.com> <3E95E8E9.3080102@ludd.luth.se> <3E95F03C.2A01561D@mindspring.com> <3E96CA1F.4070000@ludd.luth.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Mattias Pantzare wrote: > Terry Lambert wrote: > > 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. I rather expect that the number of jumbogram buffers on FreeBSD is tiny and/or your MTU is not being properly negotiated between the endpoints, and you are fragging the bejesus out of your packets. A good thing to look at at this point would be: o Clean boot of FreeBSD target o Run NetBSD against it o Save statistics o Clean boot of FreeBSD target o Run FreeBSD against it o Save statistics o Compare saved statistics of NetBSD vs. FreeBSD against the target machine > And packet loss will affect the performance diffrently if you have a > large bandwith-latency product. You mean "bandwidth delay product". Yes, assuming you have packet loss. From your description of your setup, packet loss should not be possible, so we can discount it as a factor. You may want to disable fast restart on the FreeBSD sender. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E96E873.9CC19544>