OLPC "iperf hang" notes

[Mitch Bradley]

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
>> Devel at laptop.org
>> http://mailman.laptop.org/mailman/listinfo/devel
>>
>
>