[Top][All Lists]
[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
>
- RE: [lwip-users] Simulation of TCP connections with multiplesourceIP addresses, (continued)
- Re: [lwip-users] Microblaze and lwIP,
jcr_alr <=