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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://lists.nongnu.org/mailman/listinfo/lwip-users >> > _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
