Re: [lwip-users] TCP performance in receiving

[Atte Kojo]

K.J. Mansley wrote:
> What I don't understand (and which your suggested fix has reminded me to
> ask!) is why the next received packet does not result in the delayed ACK
> being dispatched.  The reason the suggested fix works, is that tcp_ack()
> gets called twice for each received packet (once in tcp_receive() and
> once in tcp_recved()).  Because we ensure that there are no more than
> two delayed acknowledgements, the second call sends an ack immediately. 
> However, this shouldn't be necessary (and I can see now why the check in
> tcp_recved() is there - it's just doing a window update rather than a
> full ACK), as if the stack continues to receive data, the next received
> packet will cause tcp_ack() to be called, and an ACK dispatched then. 
> i.e. If a stack is constantly receiving data, ACKs should never need to
> wait for a timer to expire before they are sent.

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.

> The only way I could see this breaking down is if the TCP segment size
> is similar to the TCP window size.  Then, a single segment will close
> the whole window, needing an ACK to open it again before any other
> segments can be sent, but the ACK is delayed waiting for another
> segment.  If that is the cause of the problem, I would class it as a
> misconfiguration (the max segment size should not be as large as the
> window) rather than a bug in lwIP.
>
> Could you check what your TCP_WND and TCP_MSS are set to?

I tested this using TCP_WND 4096 with TCP_MSS 1024 and 512. The problem 
persisted, although decreasing MSS makes the aforementioned events more 
infrequent.

        - Atte

--
6. "That's okay, I'd like to keep it on manual control for a while."
        - Top 10 suggestive lines from Empire Strikes Back