On Wed, 2005-05-25 at 15:51 -0700, Eric Knudstrup wrote: > I'm using lwIP 1.1 with all of the latest updates and I'm having some > trouble. > Against a Linux 2.4 server, data reception is disgustingly slow. > Basically what happens is that when lwIP sends one of its duplicate acks > the server will then wait 200ms and resend the packet that was acked? > An ethereal trace is attached. Note packet 12, which is acked by packet > 13.
No, packet 13 ACKs packet 10. > Then it is acked again by packet 15. The linux box waits 200ms > before *retransmitting* packet 12? The sequence looks fine to me. There is some problem with the packet 12 when it is received or lost, and so this is not ACKed. Instead, packet 10 is ACKed twice (packets 13 and 15) as should be done, and if another packet had been received in the stream packet 10 would have been ACKed a third time. However, as the window is small there aren't enough packets in the stream to do this and so the fast retransmit (which needs 3 duplicate ACKs) can't kick in. After a 200ms timeout, the other end retransmits that oldest unacknowledged packet, which is 12 (the one that had a problem, we presume). The receiver gets this and then ACKs all the outstanding data (packets 12 and 14) in packet 17. The only question is why packet 12 was rejected the first time. I presume this dump was captured at the linux side, so it's possible the packet could have been lost or corrupted in transit, but given the low level of traffic (and assuming there wasn't other traffic on your network) that seems unlikely. Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
