Re: [lwip-users] TCP performance in receiving

[K.J. Mansley]

On Mon, 2004-10-11 at 10:44, Craig Graham wrote:
> I just ran a few tests using Atte's approach to the issues with tcp_recved(),
> and the results are astonishing - using libCurl to do HTTP transfers over 
> ethernet from an apache server on the local subnet, lwip's download 
> performance goes up massive enormously (based on time taken to download a 
> large (several MB) file). I also tryed Bo-Er's approach of reducing the 
> TCP_FAST_INTERVAL, which gives some improvement in download rate, but nowhere 
> near as noticable as the mod to tcp_recved().
> 
> Here's the comparison:
>                                  Time       %performance
> Stock 1.0.0 (with cvs mods)      74s        100% (baseline)
> TCP_FAST_INTERVAL=100s           69s        107%
> tcp_recved() mod                 29s        255%
> tcp_recved() + TCP_FAST_INTERVAL 26.7s      277%

That is as I would expect if ACKs are not getting sent in a timely
manner.

> Anyway, as Atte didn't actually post his modified version of tcp_recved(), 
> here's my interpretation (used to get the above figures):

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.

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?

Thanks

Kieran