CURRENT branch and older OSes

Russ Allbery rra at stanford.edu
Sun Mar 22 19:07:59 UTC 2009


Julien ÉLIE <julien at trigofacile.com> writes:

> There were many more exchanges per second before (with INN 2.4.x).
>
> The Doctor reports that this patch (which I adapted from something David
> Canzi suggested two years ago) for nnrpd/nnrpd.c makes INN 2.5.0 as fast
> as INN 2.4.x on his BSD/OS:

> +    setsockopt(STDIN_FILENO, IPPROTO_TCP, TCP_NODELAY, &nodelay, sizeof(nodelay));

    TCP_NODELAY
           If set, disable the Nagle algorithm.  This means that segments
           are always sent as soon as possible, even if there is only a
           small amount of data.  When not set, data is buffered until
           there is a sufficient amount to send out, thereby avoiding the
           frequent sending of small packets, which results in poor
           utilization of the network.  This option is overridden by
           TCP_CORK; however, setting this option forces an explicit flush
           of pending output, even if TCP_CORK is currently set.

http://en.wikipedia.org/wiki/Nagle's_algorithm

I suspect that TCP delayed acknowledgements are in play on BSD/OS, based
on the Wikipedia article, and so this system is seeing the ACK delay
problem.  Why this would change with versions of INN I have no idea.

> Should we make that TCP_NODELAY option deactivable?
> ("nnrpd -d" *not* to use TCP_NODELAY)

I'd be inclined to only enable it on BDS/OS if we've not seen the problem
elsewhere.  Ideally, we should only enable it when TCP delayed
acknowledgements are enabled, but I'm not sure if we can determine that.
Normally, Nagle's algorithm is a performance optimization that we want
(think collecting the pieces of an OVER reply into one packet).

> Should TCP_NODELAY be also set to other programs?  Where?
> (And Why STDIN_FILENO?)

I suspect it really wants to be setting it on STDOUT_FILENO and they just
happen to be the same stream in the normal nnrpd case.  Disabling Nagle's
algorithm on an incoming stream is meaningless since the algorithm
controls packet transmission.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.



More information about the inn-workers mailing list