Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jul 1999 16:12:46 -0500 (CDT)
From:      Jonathan Lemon <jlemon@americantv.com>
To:        mike@smith.net.au, hackers@freebsd.org
Subject:   Re: tcp windowsize query? 
Message-ID:  <199907142112.QAA10842@free.pcs>
In-Reply-To: <local.mail.freebsd-hackers/199907142021.NAA01388@dingo.cdrom.com>
References:  <local.mail.freebsd-hackers/199907142008.QAA69071@bb01f39.unx.sas.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-hackers/199907142021.NAA01388@dingo.cdrom.com> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907142112.QAA10842>