[Top][All Lists]

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

Re: [lwip-users] How could let lwIP send more without wait ACK

From: Kieran Mansley
Subject: Re: [lwip-users] How could let lwIP send more without wait ACK
Date: Tue, 20 Apr 2010 12:44:45 +0100

On Tue, 2010-04-20 at 18:24 +0800, yueyue papa wrote:
> Hi All
> I use the same server make echo for two client: one is lwIP, another
> is GPRS module TCP/IP stack.
> I send 5000 data, from wireshark lot
> Out:  1460, 1460, 1460 and 640
> And then get server ACK.
> I unable to make lwIP  send data more than 2 package without wait ACK.
> My windows is already setup as 16k.

I've had a look at the server trace, which has traffic from two
different IP addresses: and, but I'm not sure
which is lwIP. has its initial window set to 16k, which matches what you
describe above, but this end seems quite able to send multiple packets.
e.g. the sequence of frames from 33-37 shows it sending the whole 5000
bytes without an ACK.  I'm guessing therefore that it's
that is lwIP.

There are some strange retransmissions (e.g. frames 10-17) but I think
you mentioned before you're seeing ACK loss, and this could explain
that.  I'm not sure why the other end waits 13 seconds from frame 4 to
frame 10 before retransmitting though - that is much longer than it
should.  There are huge gaps between the sends at the start there too
which makes no sense.  Perhaps you're not calling the TCP timers

There are other strange gaps too: e.g. frames 22 and 23 are sent very
close together, so we would expect them to cross the network together
and be ACKed close together too, but their ACKs in frames 24 and 25 come
back more than a second apart.  Perhaps this also suggests problems with
timing in your port of lwIP.

As to the question of why it won't send multiple packets without an ACK,
there is nothing in TCP that should be limiting it from the packet
capture you show.  My guess is that the sender is so slow
(there is rarely more than 1 packet per second being sent) that the
other side stops waiting for more packets and ACKs the one it has got.
I think this because of the sequence at the start: we know that the ACKs
in frames 5,7,9 are lost (because the packets they ACK get
retransmitted) but the sender carries on sending frames 6,8.  If it
hasn't received an ACK but is still happy to keep sending, that means
it's not TCP that is limiting the rate.

It's much more likely that there's a problem with timing or calling into
the stack at the right points, that means that things are running very


reply via email to

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