Re: [lwip-users] Sending too slow.

[Bob Grice]

Hi Mateusz ,

The way that the packets are being sent (1460 followed by 40) is because
of an issue in tcp_enqueue that I noticed last November, unfortunately I
haven't had time to submit what would be a quite complicated patch..
The problem is benign apart from the fact it makes the link inefficient.
Tcp_enqueue first splits the received data into segments all of mss size
apart from the last, it then checks the last segment on the unsent queue
and attempts to join the segments if the last is also less then mss.
This works fine if you are doing small writes, however if you do writes
(worst case mss+1 bytes) you end up with <mss> <1 byte> <mss> <1 byte>
rather than <mss> <mss> <2 bytes>.
Basically, the code needs modifying to check the space of the last
unsent before it splits the new data into mss sized units, but this
would need quite a large patch...

I also found a bug in the implementation of the Nagle algorithm. I
noticed a distinct stop & restart occurring at a regular 200ms interval.
Furthur investigation led me to LWIP's implimentation of Nagle's
algorithm in function do_write( ).
The code currently delays transmission until the timer expires whenever
there is outstanding acks (unless TF_NODELAY), whereas Nagle requires
transmission only to be delayed if there is outstanding acks and you
can't send a MSS sized segment.

I made a quick change of the code to :

   if(err == ERR_OK && (msg->conn->pcb.tcp->unacked == NULL ||
(msg->conn->pcb.tcp->flags & TF_NODELAY) || 
     ( msg->conn->pcb.tcp->snd_queuelen) > 1) ) {
  tcp_output(msg->conn->pcb.tcp);
       }

Basically allowing the call to tcp_output if the current queue length is
more than one segment (as this implies you must have at least one full
sized one). 
I don't know if either of these changes made it into the current
surface, as I haven't been working with lwip for the last year or so,
but hopefully it will give you something to look at.

Bob Grice