lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kieran Mansley
Subject: Re: [lwip-users] Re: Long(er) delay to PC ACK when serving images
Date: Wed, 18 Oct 2006 16:12:43 +0100

On Wed, 2006-10-18 at 16:32 +0200, Janusz U. wrote:
> There is tcp tump made by ethereal. Could somebody explain me why Win=0 when 
> I transfer data with TF_NODELAY flag??? 192.168.1.48 is server (my 
> computer), 212.2.99.41 lwIP device with BSD PPP stack by GPRS.

The most that the lwIP device seems to be publishing is 512 bytes (I
think - it's quite hard to read the trace due to the way the lines have
wrapped).  This is a very small receive window, and suggests you have
configured one of the memory options too low.  It will advertise Win=0
when all of its receive window is in use, usually this means that it has
received some data but the application hasn't read them yet.  Until the
data are passed to the application that memory can't be re-advertised.

What is particularly interesting in this trace is that normally, after
advertising a zero window, the stack would send a window update
(basically just an ACK with a non-zero advertised window) to say "it's
OK, you can start sending again now" once the application has read the
data.  I don't see any of those.  Instead the other end is sending a
zero-window probe (the 1 byte packets a few hundred milliseconds after
the zero-window ACK) and this prompts the lwIP end to advertise the
available 512 byte window.  This is because lwIP will only advertise a
new window once the available memory is at least half the receive
window.  See src/core/tcp.c:399  There is a comment there explaining the
motivation - basically it tries to avoid sending a window update until
there is a reasonably sized window to advertise.  In your case it never
gets a reasonably sized window because there are only a maximum of 512
bytes available - where this limit is coming from I don't know, but I
guess it's something you've configured.

We could probably improve this check to be a less crude, but I think the
root of the problem is the amount of memory you're providing, and the
settings for TCP_WND and TCP_MSS.

Hope that helps

Kieran






reply via email to

[Prev in Thread] Current Thread [Next in Thread]