Date: Sun, 28 Nov 1999 17:05:13 -0700 (MST) From: Alex Rousskov <rousskov@ircache.net> To: David Greenman <dg@root.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Message-ID: <Pine.BSF.4.05.9911281645230.12493-100000@pail.ircache.net> In-Reply-To: <199911282341.PAA24893@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 28 Nov 1999, David Greenman wrote: > ... I've since changed my opinion > on the usefulness of delayed ACKs, however, and now think that they cause > more problems then they solve and should be shut off by default (i.e. change > net.inet.tcp.delayed_ack default from 1 to 0)...which is what I do on all > of the servers that I've built. Interesting! In our benchmarking environment we disable delayed ACKs as well. However, we were recently attacked by several vendors of the products we test. The vendors claim that turning delayed ACKs off produces too many ACK packets compared to a "real" TCP stream they observe in practice. Those "extra" ACKs might overflow their NICs/adapters when they are close to their performance capacity. The vendors also say that Linux TCP stack does not emit that many ACKs while not suffering from extra delays that default FreeBSD settings create (i.e., Linux folks allegedly found some magic "golden middle" that satisfies everybody). We have not verified these claims. Now we are considering enabling delayed ACKs (the default) to stop vendor complains. Would be great if anybody out there could provide an "independent" statistics (or at least an opinion) on the real TCP streams and the presence of delayed ACKs in other TCP stacks. Any comments? Thanks, Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9911281645230.12493-100000>