OLPC "iperf hang" notes

[Ronak Chokshi]

I have uploaded .txt format of the sniffer captures in two separate .zip
files. Please refer to those.

My bad.

Thanks
Ronak

-----Original Message-----
From: Ronak Chokshi 
Sent: Thursday, March 01, 2007 3:12 PM
To: 'Mitch Bradley'; javier at cozybit.com
Cc: mtosatti at redhat.com; David Miller; devel at laptop.org
Subject: RE: OLPC "iperf hang" notes

Hi Mitch, et al.
I have posted some other comments as well on the same ticket. We have
done some UDP tests on the on-board WiFi device and also on an external
WiFi dongle.

http://dev.laptop.org/ticket/915

Thanks
Ronak

-----Original Message-----
From: devel-bounces at laptop.org [mailto:devel-bounces at laptop.org] On
Behalf Of Mitch Bradley
Sent: Thursday, March 01, 2007 3:08 PM
To: javier at cozybit.com
Cc: mtosatti at redhat.com; David Miller; devel at laptop.org
Subject: Re: OLPC "iperf hang" notes

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