CURRENT branch and older OSes

[The Doctor]

On Sun, Mar 22, 2009 at 12:07:59PM -0700, Russ Allbery wrote:
> 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.
>

Suggestion why not deal with this based on an OS basis?
 
> -- 
> 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.
> _______________________________________________
> inn-workers mailing list
> inn-workers at lists.isc.org
> https://lists.isc.org/mailman/listinfo/inn-workers
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 

-- 
Member - Liberal International	This is doctor at nl2k.ab.ca
Ici doctor at nl2k.ab.ca God, Queen and country! Beware Anti-Christ rising!
Never Satan President Republic!
Point to http://tv.cityonahillproductions.com/ 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.