RE: [lwip-users] FTP-DATA exchange: advice needed

[Tom C. Barker]

Kieran,
I am using tcpip_input to communicate with the stack
via the ISR in case the assumption was that I was 
running the full stack in real time. Thanks again.
Tom




-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf
Of Tom C. Barker
Sent: Tuesday, February 22, 2005 11:01 AM
To: Mailing list for lwIP users
Subject: RE: [lwip-users] FTP-DATA exchange: advice needed


Thanks Kieran. I'll look around. The file is being 
written to compact flash so that slows down things
on the receiver, but it is a bother that the ACK 
takes so long. I'm in an multithreaded environment 
on a Coldfire 5282 at 50 MHz and very little is 
taking up the processor time.

There has been very little done to the stack: only a 
few mods to get the 4-byte alignment to work properly. 

I'll inform the list what I find.

Thanks again for taking the time.

Tom


-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf
Of Kieran Mansley
Sent: Tuesday, February 22, 2005 10:20 AM
To: Mailing list for lwIP users
Subject: RE: [lwip-users] FTP-DATA exchange: advice needed


On Tue, 2005-02-22 at 09:30 -0800, Tom C. Barker wrote:
> Attached is the truncated dump: only familiar with
> dumping files from the gui in Windows, I looked 
> around and found editcap.exe to convert the dump
> to the form you had requested.

Great, thanks.

First off, you seem to have a very slow node (216.101.63.81)!  It takes
it well over a second to respond to the SYN-ACK (packet 2) with an ACK
(packet 3).  This suggests either it's seriously underpowered, or
there's something wrong: it could be that it only goes at all because of
a timer (like the slow timer) firing.  Check that you are servicing the
stack correctly.

Secondly, there is quite a lot of loss for such an uncongested link.
There are certainly a number of retransmissions anyway, although with
many of them they appear to be for data that was transmitted fine the
first time.  (Could be it went missing between where the trace was
captured and the other end though).  Some of the retranmissions can also
be attributed to the "81" node taking a very long time to ACK them.

Thirdly, the fact that the advertised window is getting smaller and
smaller all the time suggests another problem.  This indicates that the
application on the "81" node is even slower than the stack (which is
pretty incredible, given how slow the stack seems to be running!) and so
data are backing up waiting to be read.  This means the stack can't
advertise those buffers to the other side, and eventually the window
goes down to less than 1 segment (1450 < 1460 bytes).

When the window is less than 1 segment, the sender may wait for a while
in the expectation that it'll get another ACK soon with a larger window,
and so enable it to send a whole segment rather than a fragment.  This
is Nagle's algorithm.  The sender is probably doing this.  One odd thing
here is that Nagle says you should only delay sending if you already
have any unacknowledged data in flight (i.e. something that you've sent
that hasn't been acked).  This is not the case in this example, so I'm
guessing the sender is doing something like Nagle, but not conforming to
the spec.  Many stacks won't send any data to a stack advertising less
than 1 MSS of window at all just to try and be more efficient.

So, to summarise, I would find out:
(i) why your receiver is so slow
(ii) why the reading application isn't able to keep up (or why, if it
is, does the advertised window get smaller and smaller)
(iii) if you can't change either of those, how you can alter the
behaviour of the sender to not wait so long before sending to a node
that advertises a window < 1 MSS

Hope that helps,

Kieran



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users