Re: [lwip-users] TCP performance in receiving

[K.J. Mansley]

On Mon, 2004-10-11 at 12:22, Atte Kojo wrote:

> I did some investigations, and here is the problem outlined. I have a 
> data source that sends lots of data in rapid bursts, and an application 
> using lwIP that takes time processing the said data. When the source 
> sends out a large burst of data, it rapidly uses up its send window 
> (given by my lwIP stack). Now, because my application hasn't yet 
> processed any data, the send window is very small for the acks 
> tcp_receive() sends. The source starts waiting until the window gets 
> bigger. After my application has processed data and the window size is 
> increased, tcp_recved() sees that a TF_ACK_* flag is set and sends out 
> nothing. After 250 ms tcp_fasttmr() kicks in and sends the delayed ack 
> and source again continues sending. Until same thing happens again.

Thanks for your detailed response, it's much appreciated.  It sounds
like all the data is getting processed by each stage in batches, and so
tcp_receive() processes all the received data (and acknowledges it with
a small window), and later the application processes and opens the
window, but this "window-update-ACK" doesn't get through till a timer
fires, as by then the sender has stopped sending.  Is that right?  It
was this delay between receiving and processing that I was missing.

At a guess, your application reads a large block (ie. similar to the
window size) of data in one go from the stack, and calls tcp_recved()
just once for that large block?  Is that correct?

Obviously, a larger window would make it possible for the sender to keep
streaming, and then the window updates would get sent promptly, but that
may be something that the memory limited lwIP users can't afford to do.

It's a tricky problem to solve without causing another problem for
another data pattern (i.e. duplicate ACKs sent when the application
processes data in small chunks as fast as the stack will deliver them). 
Perhaps a threshold in tcp_recved() would help, so that if the window is
currently very small, it sends an ACK immediately.  If it's larger, and
there is an ACK already outstanding, it does what it does now.  Do you
think that would help in your situation?

Kieran