From owner-freebsd-net Sun Nov 28 16: 5:49 1999 Delivered-To: freebsd-net@freebsd.org Received: from pail.ircache.net (pail.scd.ucar.edu [128.117.28.5]) by hub.freebsd.org (Postfix) with ESMTP id 6927E153BF for ; Sun, 28 Nov 1999 16:05:46 -0800 (PST) (envelope-from rousskov@ircache.net) Received: from localhost (rousskov@localhost) by pail.ircache.net (8.9.2/8.8.7) with ESMTP id RAA12521; Sun, 28 Nov 1999 17:05:13 -0700 (MST) (envelope-from rousskov@ircache.net) Date: Sun, 28 Nov 1999 17:05:13 -0700 (MST) From: Alex Rousskov To: David Greenman Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs In-Reply-To: <199911282341.PAA24893@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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