From owner-freebsd-net Mon Nov 29 14:50:18 1999 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id B19421548D for ; Mon, 29 Nov 1999 14:50:15 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id OAA27538; Mon, 29 Nov 1999 14:49:36 -0800 (PST) Message-Id: <199911292249.OAA27538@implode.root.com> To: Alex Rousskov Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs In-reply-to: Your message of "Sun, 28 Nov 1999 17:05:13 MST." From: David Greenman Reply-To: dg@root.com Date: Mon, 29 Nov 1999 14:49:36 -0800 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. That sounds very lame. >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. It could be that delayed ACKs aren't delayed as long in Linux. We could do the same thing in FreeBSD by shortening it down to say 10ms or something. That would allow the ACKs to be aggregrated with the character echoes while still keeping the response time fairly quick. Delayed ACKs are evil in other ways, however. For one thing they add noise and additional delay to the estimated RTT. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message