[lwip-users] Re: Long(er) delay to PC ACK when serving images

[Alan Lamphier]

Kieran Mansley <address@hidden> writes:

> 
> On Sat, 2006-10-07 at 01:01 +0200, Mateusz Plocinski wrote:
> > Hi,
> > I'm not an tcpip expert too, but I've worked with lwip for past few weeks. I
had exactly the same problem like
> yours, also using SAM7X256 processor.
> > I solved the problem changing following thing in api_msg.c:
> > 
> > /* This is the Nagle algorithm: inhibit the sending of new TCP
> > segments when new outgoing data arrives from the user if any
> > previously transmitted data on the connection remains
> > unacknowledged. */
> > 
> > //      if(err == ERR_OK && (msg->conn->pcb.tcp->unacked == NULL ||
(msg->conn->pcb.tcp->flags &
> TF_NODELAY)) ) {
> >   tcp_output(msg->conn->pcb.tcp);
> > //      }
> 
> A better solution would be the one mentioned in this post to the mailing
> list:
> 
> http://lists.gnu.org/archive/html/lwip-users/2006-09/msg00060.html
> 
> Hopefully this change (although probably not the enqueue problem
> mentioned there) will make it into the main tree soon.
> 
> Thanks
> 
> Kieran
> 

In looking at implementing the Nagle algorithm suggestions, I see I’ve
previously found the suggested improvement thread and was running the Nagle
update, checking if snd_queuelen > 1.  Backing the code back out to the original
lwIP file without the queuelen check, my web page transfer with images takes
much longer to load (>1s compared to 190ms).  The same was true if I commented
out the "if(err == ERR_OK..." statement.

My max packet len when calling netconn_write() with a piece of the image still
has to be 730 bytes or less or the longer delay to PC ACK returns.  In fact
today, to add haze to the problem, the max packet size has to be a bit less
(~700 bytes) to eliminate the PC ACK delays.  

A max packet size of 730 bytes when running TCP_MSS = 1460 seemed too related to
be a coincidence, but I still can't find the dependencies to get my image packet
sizes back up to max.

Thanks for the leads and any other ideas one might have,
Alan