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

[yueyue papa]

windows server: 192.168.8.94
GPRS module(TCP/IP):  117.136.8.162

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 ---------------->
-----------------------------------------1460----------------->
------------------------------------------1460----------------->
--------------------------------------------640----------------->

<----------------ACK--------------------------
<----------------ACK--------------------------
<----------------ACK--------------------------
<----------------ACK--------------------------


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


GPRS TCP/IP module     -               Windows Sever

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

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: 192.168.8.94
> GPRS module:  117.136.8.162
>
> 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: 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
>>
>>
>>
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>