[Tfug] Linux kernel tcp delay options 4e7uzube

[Adrian]

On Thursday 06 June 2013 14:49, Bexley Hall wrote:
> Hi Adrian,
>
> > Yep, the best option would be for the app to use TCP_NODELAY when opening
> > its socket... but alas Cyrus doesn;t do this, at least not in the CentOS
> > 5.x package I have. There are lots of threads about this and dev comments
> > that Cyrus should do this from several years back... but it apparently
> > didn;t get in (which really suprises me that no one has fixed this in the
> > last 10 years since I last used Cyrus).
>
> Is there a counterargument as to why it "shouldn't"?  I.e., perhaps
> <someone> intended it for use in a type of application where this
> would be counterproductive?  Though one can argue for a configurable
> option -- perhaps even "client/account specific"!  (Having a *core*
> RDBMS service running in an OS should be a key requirement for any
> OS "heavy" enough to support it!  Shame that this hasn't been the
> case to date!)

I can't think of any of the top of my head. TCP ack delay/nagle is very useful 
for reducing packet load on very slow data streams (like typing or serial 
transfers) at the expense of latency. It waits for more data to try to send a 
single large packet instead of many small packets. On fast datastreams or 
large transfers it is irrelevant as the packet data is filled long before the 
timer expires.

With IMAP, the server doing lots of small "OK" response packets in response to 
every client command request. If the kernel holds every "OK" data packet 
waiting for more to fill a packet, it can introduce a lot of latency.


Adrian