lwip-users
[Top][All Lists]
Advanced

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

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


From: Jim Gibbons
Subject: Re: [lwip-users] FTP-DATA exchange: advice needed
Date: Tue, 22 Feb 2005 12:13:02 -0800
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Sorry to be piping into your exchange with Kieran, but the mention of the ISR brings up an issue that I have faced in the past.

You should check your lwipopts.h and be sure that you have
 #define SYS_LIGHTWEIGHT_PROT            1
Anything else will give you troubles.  tcpip_input calls memp_mallocp, which in its turn tries to defend itself from re-entrance while it is allocating memory.  Only the lightweight method will work from an ISR.  You should also check your definitions of the SYS_ARCH_PROTECT stuff.  It is possible that interrupts may disabled while in your ISR.  If this is the case, you will want to be sure that OS_CRITICAL_METHOD is defined to be 3.  This is often in cpu.h.

I personally prefer to use the lightweight protections in all lwIP implementations.  I don't think that the protections for pbuf allocations really work with any other selection.

Tom C. Barker wrote:
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]On 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]On 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


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

--
Jim Gibbons
address@hidden
Gibbons and Associates, Inc.
TEL: (408) 984-1441
900 Lafayette, Suite 704, Santa Clara, CA
FAX: (408) 247-6395



reply via email to

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