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

[Kieran Mansley]

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: 192.168.8.94 and 117.136.8.162, but I'm not sure
which is lwIP.

192.168.8.94 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 117.136.8.162
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
correctly?

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 117.136.8.162 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
slowly.

Kieran