In Javier's trace, only 26 packets were transmitted, whereas in each of
my test runs, there were exactly 29 outgoing packets. So I guess the
"29" number is not exactly repeatable.
I wonder what is causing the packet reordering? Does iperf explicitly
force reordering in order to stress test the TCP? I would expect
out-of-order packets to be extremely rare - virtually nonexistent -
within the confines of a single machine.
Javier Cardona wrote:
Hi Mitch,
I took a over-the-air capture of the transmitted frames and repeated
your analysis. This is the sequence that I got:
2 4 1 3 5 7 9 6 10 8 11 12 14 16 13 17 15 18 19 20 21 * 23 24 25 26 27
(I uploaded the capture here http://dev.laptop.org/ticket/915, "*" is
for packet 23)
The TCP trace acknowledgments up to packet 20. This last
acknowledgement is repeated 6 times and after that the connection is
frozen.
Javier
I decoded the packets in the USB trace. There is a lot of packet
reordering going on - the sequence numbers don't increase monotonically.
Subtracting out the first sequence number and dividing by the constant
fixed length of the outgoing packets, the sequence is:
0 1 4 6 2 3 7 5 8 9 11 13 10 14 12 15 16 18 20 17 21
19 22 23 * 25 * 27 28 29 30
The ACKs work as expected, i.e. when the sequence fills in, the ACKs
catch up.
"*" shows a sequence number that never showed up - packets "24" and "26"
were not transmitted. The ACK sequence stalled after "23", reflecting
the fact that 24 never arrived.
I killed the process 12 seconds after progress stalled (i.e. after point
"30'). There were no retransmissions during that time.
_______________________________________________
Devel mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/devel
