Re: [lwip-users] Disable Nagle Algorithm

[Kieran Mansley]

On Fri, 2011-04-08 at 09:48 +0200, address@hidden wrote:
> Hi all!
> 
> I'm using LWIP on an application where I send various amounts of data.
> Now I have the problem that the transmission is quite slow sometimes.
> Please find attached a wireshark protocol for better explanation.
> I disabled the nagle algorithm with the macro tcp_nagle_disable(tcp_).
> But as you can see in the procotol, for example from package 12 to 13 
> lwip waits for more data to be sent and doesn't send the data immediately.
> Thanks in advance for your help!

I'm assuming that lwIP is the sender, i.e. 192.168.10.40 (why does no
one ever include this information when sending packet captures?!) but
please let me know if I've got that wrong.

The delay between packets 12 and 13 is because lwIP is waiting for an
acknowledgement from the other side before sending more data, and the
other side is delaying acknowledgements to try and reduce the number of
acknowledgements.

If you've successfully disable Nagle's algorithm, then we would I think
only delay sending if:

1) The congestion window prevented it.  I'd expect this to start small
near the beginning of the connection, but to grow quite quickly to allow
more packets in flight.  As your connection is long-lived this therefore
doesn't explain it later on.

2) The receive window prevented it.  The receiver is advertising plenty
of window, so this isn't an issue.

3) There wasn't any more data in the send queue.  This might be the
problem, depending on how you've configured lwIP, and how your
application sends data.  lwIP can only send what it is given, so if
there isn't anything ready to send it won't be able to stream the data.
Can you show us your lwipopts.h file to check the configuration of the
send queue? 

4) Nagle's algorithm is still enabled.

I know there were some improvements in our implementation of Nagle's
algorithm recently, but can't remember which version these went in to.
Which version of lwIP are you using?

If Nagle really is disabled and you're using a recent version of lwIP I
would look into (3).  I.e. make sure you have enough data in the send
queue so that lwIP can form another packet to send.  If the send queue
is running dry, or is so small that only one packet will fit, this might
explain the problem.

A few times in the trace we do see lwIP sending out two frames with
payload back-to-back and no ACK in-between.  The first of these is
always missing the PSH bit, whereas when we're waiting for an ACK the
frame always has the PSH bit set.  I'm guessing (from the way you're
calling tcp_disable_nagle()) that you're using the raw API.  If this is
the case, how does your application call tcp_write()?  And does it also
call tcp_output()?  And does it set TCP_WRITE_FLAG_MORE when calling
tcp_write()?

Kieran