Re: net.inet.tcp.delayed_ack value?
Re: net.inet.tcp.delayed_ack value?
- Subject: Re: net.inet.tcp.delayed_ack value?
- From: Greg Shenaut <email@hidden>
- Date: Sat, 8 Mar 2008 18:22:44 -0800
On Mar 8, 2008, at 4:22 PM, Andre-John Mas wrote:
I recently came across this hint at MacOS X hints, suggesting a
solution to speed up Airport transfer speeds:
http://www.macosxhints.com/article.php?story=20080305053403936
Basically it suggests entering the following:
sudo sysctl -w net.inet.tcp.delayed_ack=0
From what I have been told this current setting is based on Nagle's
algorithm, but reading up on it at Wikipedia I see:
"This algorithm interacts badly with TCP delayed acknowledgments, a
feature introduced into TCP at roughly the same time in the early
1980s, but by a different group. With both algorithms enabled,
applications which do two successive writes to a TCP connection,
followed by a read, experience a constant delay of up to 500
milliseconds, the "ACK delay". For this reason, TCP implementations
usually provide applications with an interface to disable the Nagle
algorithm. This is typically called the TCP_NODELAY option."
A responder to the MacOS X Hints article states:
"This bug has been documented for quite some time now, and NetBSD
fixed".
Is the current approach indeed outdated, needing borrowing changes
from the NetBSD stack, or are there particular scenarios the NetBSD
implementation handles badly?
I don't know if you've seen this: <http://www.stuartcheshire.org/papers/NagleDelayedAck/
> but it's a very interesting read, and it explains exactly what is
going on with the delay.
Greg Shenaut
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden