Notes on "iperf hang" problem.
Under Marcelo's supervision, I run iperf in server mode on one XO, iperf
in client mode on another XO, communicating via the internal Marvell
wireless on server XO and an external Marvell wireless dongle on the
client XO.
I used a USB analyzer to observe the USB traffic to the wireless dongle
on the client.
At the human-observable level, the client iperf quickly hangs and has to
be killed.
I looked at USB traces from several different iperf runs. The same
thing happened every time:
a) An initial exchange of a few short TCP packet exchange that was
probably setup.
b) 29 closely-spaced repetitions of the following exchange:
1) Client sends a 1500 byte TCP segment to the server (spread
over 4 USB transactions 512, 512, 512, 6).
2) Server responds. The response length on the USB bus is either
98, 110, or 118 bytes, for a TCP payload size of either 12, 24, or 30 bytes.
c) The total time for the 29 exchanges was always very close to 200 mS.
d) After the 29 exchanges, there is no data traffic on the USB bus
until you kill the iperf client process. (USB polls, i.e. "Incomplete
IN transactions", continue, indicating that the USB host controller is
still functioning.)
e) The last of the 29 exchanges is well-formed and complete, i.e. the
server did indeed respond to the client's transmission.
I also used "ifconfig" and "netstat -s" to look for errors detected by
the network stack. After each iperf run, the ifconfig "TX dropped"
number increased by 9, and several error numbers in the netstat -s
"TcpExt" section increased. I no longer have the exact data from
netstat -s, but I recall an increase in some counters related to "SACK",
as well as at least one other error counter.
_______________________________________________
Devel mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/devel
