From owner-freebsd-hackers Wed Jul 14 14:13:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id D3CD3153EF for ; Wed, 14 Jul 1999 14:13:49 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id QAA11395; Wed, 14 Jul 1999 16:12:48 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id QAA01682; Wed, 14 Jul 1999 16:12:46 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id QAA10842; Wed, 14 Jul 1999 16:12:46 -0500 (CDT) Date: Wed, 14 Jul 1999 16:12:46 -0500 (CDT) From: Jonathan Lemon Message-Id: <199907142112.QAA10842@free.pcs> To: mike@smith.net.au, hackers@freebsd.org Subject: Re: tcp windowsize query? X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: References: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >> delayed ack sounds interesting.... > >Turning that off disables TCP slow-start. It's a huge performance >booster for things like SMB service, where you have lots of short-lived >TCP connections on a local net. Mike probably already knows this, but just a general clarification: No, it does _not_ turn off slow-start. Normally a TCP implementation will delay sending an ACK to the peer until the TCP fasttimer expires, or certain other conditions are met. The goal here is to amortize an ACK over several incoming data packets. Turning off delayed ack forces the receiving end to send an ACK immediately, for every packet it receives. This may or may not result in a performance boost. For short lived connections, where latency is paramount, it usually results in a gain, since there is no delay in sending an ACK. For longer lived connections, it results in more network traffic, usually resulting in a performace drop. Slow start is where the sender builds up to the maximum TCP window size at an exponential rate, proportional to the rate of which ACKs are returned by the peer. It is automatically disabled for hosts on the "local network", but enabled otherwise. I'm considering putting in a sysctl knob to always do slow start, even for a local network. If this happens, it would be conceivable that you could twist it the other way and never do slow start. Note that while this might be useful in certain benchmark corner cases, it would violate the RFC, and be network-unfriendly to boot. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message