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

[Tom C. Barker]

This is a report of the issues I found in my 
very slow running ftp application.

Thanks Kieran for all your help.
Thanks Jim also for your reply. ( SYS_LIGHTWEIGHT_PROT was\is 1 )


1. The window was being whittled down AND I was having
   multiple resends because I had chained pbufs which were
   not being serviced ( ack'd )by the lwIP ftp server
   in accepting the upload of a file. This forced the window
   to be ever smaller and smaller because the data being sent
   was not "getting through"...its the whole connection-guarantee
   idea in TCP. (Comments open to all experts.) Essentially, the 
   application was receiving the first of 3 chained pbufs, not 
   checking to see if ->next != null and just blowing out all 
   of the rest of the currently received data (ACKing on the first
   pbuf). Also, I found that I was sending all information from 
   the _poll function as opposed to using the ultimately efficient 
   _sent funtion.

2. I had assertions turned on (ugh!) in TCPIP and so the memp_free
   call was delaying ACKs by 50 of the 51 milliseconds used to
   process the ACK. Now my ACK is immediate (1 millisecond).

Thanks again!

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