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

[yueyue papa]

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
>