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'; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; David Miller; [email protected] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mitch Bradley Sent: Thursday, March 01, 2007 3:08 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; David Miller; [email protected] 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 >> [email protected] >> http://mailman.laptop.org/mailman/listinfo/devel >> > > _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
