TCP delayed acks not being delayed?

Bill Moran wmoran at collaborativefusion.com
Sat Mar 25 21:25:15 UTC 2006


RW <list-freebsd-2004 at morbius.sent.com> wrote:

> On Saturday 25 March 2006 02:09, RW wrote:
> > I have a 1MB/0.25Mb ADSL connection and have an IPFW rule to prioritize
> > outgoing empty acks. If I download a single file with kget at 100 kbytes/s,
> > I see that the rule gets hit at a rate of  50/s: ie a little under 1
> > empty-ack per incoming packet.
> >
> > I have:
> >
> > net.inet.tcp.delacktime: 100
> > net.inet.tcp.delayed_ack: 1
> >
> > which I thought should limit each TCP connection to <=10 empty acks per
> > second

Are you sure you're not exceeding the capability of the system to delay
acks?

If the receive window drops to 0, the receiving machine _has_ to send an
ack, or the data transfer will stall and your performance will suck.
It's not terribly difficult to imagine receive buffer vs. transmissions
speed combinations that would force it to send empty acks.

You might want to use ethereal or tcpdump to analyze the window sizes on
your data transmission.  I'm guessing that zero sized windows are forcing
the acks to be sent.  Besides, when you're transferring data in one
direction only, it doesn't make sense to delay empty acks.  only on a
full-duplex transmissions do you get a benefit by taking measures to
ensure that all packets have data.  When you're downloading, _all_ your
acks are empty, so who cares?

Additionally, if the client application turns nagle off, this will
disable the use of delayed acks.  For things like file transfer, it's
pretty much typical practice to disable nagle, as it generally doesn't
help performance, and occasionally hurts it.

-- 
Bill Moran
Potential Technologies
http://www.potentialtech.com


More information about the freebsd-questions mailing list