lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Microblaze and lwIP


From: jcr_alr
Subject: Re: [lwip-users] Microblaze and lwIP
Date: Tue, 08 May 2007 17:24:40 -0300
User-agent: Internet Messaging Program (IMP) 3.1

Hi Kieran,

Thanks for the fast response. The changes in tcp_out.c are

A)
//in tcp_enqueue() around line 260 after 
TCPH_FLAGS_SET(seg->tcphdr, flags);
// added the following
if(seglen == pcb->mss)
        TCPH_SET_FLAG(seg->tcphdr, TCP_PSH);

B)
In tcp_output(), in the while phrase that calls tcp_output_segment(seg, pcb) a 
new condition  was added (line 456 approx) to make sure that the second 
(partial) seqment was sent consecutively, thus:

        while (seg != NULL &&
                ( (ntohl(seg->tcphdr->seqno) - pcb->lastack + seg->len <= wnd) 
                                ||  (TCPH_FLAGS(seg->tcphdr) & TCP_PSH) )) 

I think the window space on the PC was some 64K. I had considered padding out 
the second segment to 1460 bytes to force an ACK but decided that was really 
giving up the battle too easily.

This problem was for a while obscured by another problem in that the PC was 
sending the FIN or FIN/ACK ACK too quickly for the Microblaze (server) end 
which wound remain in the FIN_WAIT_2 state condition for several seconds with 
various RSTs being exchanged until the segment was finally destroyed. I could 
not get the logic worked out exactly as the server always reached FIN_WAIT_2 
but acted almost as if it was still in FIN_WAIT_1. A very short delay was 
enough to cure this problem. Timing throughout was observed using an ANT8 logic 
analyser fed by a Microblaze FSL link with a time resolution of some 30 
nanoseconds.

John.


Quoting Kieran Mansley <address@hidden>:

> On Tue, 2007-05-08 at 10:41 -0300, address@hidden wrote:
> > I am not sure why this modification was necessary - are there any settings
> in 
> > either lwipopts or Winsock that I could have changed to avoid this. I think
> the 
> > problem may lie more in the PC end - because in the original implementation
> the 
> > first segment was sent without PSH and the client then maybe waited for
> some 
> > timeout period before realising nothing more was coming, then sent the ACK
> at 
> > which time the host responded sending the second partial segment that was 
> > marked PSH.
> 
> Can you explain what modification you made to the while loop in
> tcp_output() ?  I'm guessing you allowed it to send the second segment
> even if there was insufficient window space for it?  It is this change
> that is most likely getting the results you need.  
> 
> You are correct that it is the windows end that is causing your problem.
> Most TCP stacks have a "delayed ACK" policy.  i.e. In certain conditions
> they won't send an ACK in the hope that the connection involves bi-
> directional traffic and the ACK will be able to piggyback on a returning
> data packet.  In your case there is no returning data packet, and so the
> ACK isn't sent until a timer goes off after about 200ms.  However, the
> stack should acknowledge at least every other packet.  This is why if
> you modify lwIP to send both packets, they get ACKed immediately.  The
> windows end has received two packets and so must send an ACK straight
> away.
> 
> Unfortunately, this is just a property of TCP, rather than either lwIP
> or windows having a bug.  I think linux has some clever stuff in it to
> notice when the delayed ACK protocol would harm performance and so is
> able to turn it off in cases like this.
> 
> To find out more, have a look through the TCP RFCs for "delayed ACK".
> These are relatively well documented problems!
> 
> Kieran
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> 







reply via email to

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