Severely delayed (15s) ACK on inbound NNTP packets causing hung c hannels

[Russ Allbery]

Wyer, Brett <brett.wyer at telecheck.com> writes:

> Over the last few months I've been running into a problem with INN v2.x
> and was hoping that someone could either tell me what's wrong, or
> possibly point me in the right direction as to how to track the problem
> down.  Basically, the problem manifests itself as our system dropping
> somewhere between 50-75% of our inbound news.  After a bit of testing, I
> was able to determine that (based on sniffer traces) individual channels
> are sitting and waiting for my system to return a TCP ACK before
> shipping more information.  According to my sniffer traces, this can be
> for up to 15 seconds.

> Now for the strange part.  Occasionally, all six of my channels from one
> provider will be in this state.  During this time, there is NO activity
> on my system--CPU's (4) are 100% idle, no disk I/O, nothing.  Once the
> 15 seconds elapses, bing! the feeds start going again.

Are you still seeing this problem?  This sounds very odd, and I'm inclined
to suspect the network or an operating system bug of some kind.  INN
shouldn't have any control over when TCP ACKs are sent.

> - Does the OS wait to send a TCP ACK until a buffer is flushed by the app
> (assuming the window is full)?

Packets should be ACKed as soon as they're received by the networking
stack and queued for the application to read.  It may sometimes take INN a
while to read the input, but certainly not 15 seconds, and the system
would have to be busy at the time.

> - What section of code in INN is responsible for this buffering?

chan.c I believe.

> - Is there a specific reason a 24K buffer was chosen in rc.c?  (I ask
> this question because my Cyclone feed keeps trying to grow the buffer
> beyond this--I assume that the window won't grow past this limit, at
> least that appears to be the limiting factor)

Fairness, I would assume; if you have a bunch of incoming connections, you
don't want to accept too much from any one at a time and starve the
others.

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