Date: Sun, 26 Mar 2006 17:39:59 +0100 From: RW <list-freebsd-2004@morbius.sent.com> To: freebsd-questions@freebsd.org Subject: Re: TCP delayed acks not being delayed? Message-ID: <200603261740.05369.list-freebsd-2004@morbius.sent.com> In-Reply-To: <20060325162512.3ae2a4c5.wmoran@collaborativefusion.com> References: <200603250209.10994.list-freebsd-2004@morbius.sent.com> <200603250237.31122.list-freebsd-2004@morbius.sent.com> <20060325162512.3ae2a4c5.wmoran@collaborativefusion.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 25 March 2006 21:25, Bill Moran wrote: > Are you sure you're not exceeding the capability of the system to delay > acks? I would have thought not, it maxes-out with a receive space of 15k, and increasing the setting from 20k to 32k had no effect. > Besides, when you're transferring data in one > direction only, it doesn't make sense to delay empty acks. only on a > full-duplex transmissions do you get a benefit by taking measures to > ensure that all packets have data. When you're downloading, _all_ your > acks are empty, so who cares? I though I might be seeing a bug. I was only measuring it because I was thinking of switching to pf/altq and I wanted to know how much to allow for empty-acks. However, I hadn't done the arithmetic before, and I was surprized to see that 13% of my upload was being used. On a 4MB connection, that would be over half the bandwidth. Delayed acks don't affect the download speed on one tcp connection, but they could improve the performance of other traffic, when a download is taking place over a very asymmetric link. > Additionally, if the client application turns nagle off, this will > disable the use of delayed acks. For things like file transfer, it's > pretty much typical practice to disable nagle, I guess that explains it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603261740.05369.list-freebsd-2004>