On 13 Dec 2010, at 17:25, Chen wrote: > Since the ACK can take a long time to come back if the final product is > deployed over the internet. For example, if it takes 0.5 seconds for ACK to > come back, which is shorter than RTO, then the maximum data rate is 2*1460*2, > where the first 2 represents the two packets before the ACK, 1460 is the max > payload, and the second 2 is max ACK within a second, and the result is only > merely 5.8KB/sec
That's not right. The sender can carry on sending until either they have filled the window, or there is an RTO (or there is some other reason, but lets ignore those for now). In the case where there is a high round trip time (as in your example) the sender should have a high RTO as this is based on the round trip time. It will therefore be window limited and can carry on sending. The ack for every-other-packet should not limit the throughput. It sounds in your case as though the sender has estimated the round trip time as smaller than it should, and so the RTO is smaller than it should be. It could therefore be stopping sending new packets and starting to retransmit old ones too soon. This is worth looking into. The other possibility is that you've configured a small window, but the trace you showed didn't have that look about it. I'd be happy to improve lwIP's behaviour in this regard but we'd need to understand what it is doing wrong first. I'll have another look at your packet capture when I get the time to see if anything else spring to mind. Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
