[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: yueyue papa
Subject: Re: [lwip-users] How could let lwIP send more without wait ACK
Date: Tue, 20 Apr 2010 20:19:05 +0800

windows server:
GPRS module:

I like the GPRS module TCP/IP behavior,  It send as much data as
possible without wait remote ACK.

My lwIP unable to create such result:  my lwIP could only send no more
than 2 TCP segment, and then wait ACK. The network delay will cause
performance down.

I like to make lwIP send as much as possible. Is it possible to
configure for this result?


You refered not continuous to send is due to server congestion
algorithm, but I use the same sever, I could see the TCP segment send
as much as possible.


On Tue, Apr 20, 2010 at 7:44 PM, Kieran Mansley <address@hidden> wrote:
> 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
> 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 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
> _______________________________________________
> 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]