[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:29:24 +0800

windows server:
GPRS module(TCP/IP):

The captured log is not using lwIP. It is GPRS module inner TCP/IP.  I
found it could send tcp segment as much as possible.

GPRS TCP/IP module     -               Windows Sever

-----------------------------------------1460 ---------------->


If I do not use module inner TCP/IP, use lwIP for

GPRS TCP/IP module     -               Windows Sever

-----------------------------------------1460 ---------------->
<-------------ACK ----------------------
<-------------ACK ----------------------

lwIP is unable to send data as much as possible. You explain it is due
to server cause it. But the log showed it is not server cause it.  I
like to make lwIP works as GPRS module TCP/IP.

Thank you to answer

On Tue, Apr 20, 2010 at 8:19 PM, yueyue papa <address@hidden> wrote:
> 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?
> Kieran,
> 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.
> Lee
> 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]