WiFi performance and quirks
hmurray at megapathdsl.net
Tue Mar 24 18:50:10 EDT 2009
I'm not well calibrated on WiFi. I used to be pretty good at testing
Ethernets and similar networks.
I've got two machines: a c2 and an early b3. Did anything change in the
WiFi area? I know the old b3 won't sleep/wakeup correctly. Am I likely to
get confused if I use it for tesing WiFi?
I can't get more than 10 or 11 megabits throughput between a pair of XOs
sitting right next to eachother. That's XO-XO via the mesh. The XO says the
links are running at 54 megabits so I'm expecting a lot more than that.
XO-AP-XO gets about 7 megabits. I get roughly the same going from a PC
through a Linksys AP to either XO.
What are other people seeing? What should I expect? Is there a good web
page on WiFi performance? Are there any special performance quirks in the
Marvel package used on the XO?
I see occasional glitches that reduce throughput. I think that's somebody
taking time out to go probe for APs and such and the radio is deaf when
working on another channel. Are there other disruptive mechanisms?
Where is that code? Is that all at the Sugar level or does the low level
WiFi/NetworkManager stuff do similar nasty things? How often should I expect
disruptions? (I'm seeing them every minute or two I haven't looked
Large packets are flakey:
I haven't been able to get full 65K packets from my PC to an XO and back.
I'm expecting them to get fragmented and reassembled. I haven't tracked down
where packets are getting lost. 10K packets work so the
fragmentation/reassembly code all works. I've got a 10/100 switch and a 10
hub and a Linksys WRT54GL so there are many combinations and many places
where queues/buffers might overflow.
I've got one PC-XO case where 20K packets mostly work but 3oK doesn't.
65K packets work XO-XO via mesh. XO-AP-XO works about half the time at 50K.
Anyway, just a heads up in case anybody expects UDP to work with (very) large
If I send a lot of traffic between a pair of XOs, I get mashed packets. I
haven't tracked down any details beyond "errors" from ping. I'll write some
code to get more info if people are interested and somebody confirms that
this happens on other systems.
My simple test case is ping -f with long enough packets. If you make the
packets longer you will get a lot of lost packets. 10K feels "good" for
causing troubles. Here is a typical run:
bash-3.2# ping -f -s 10000 -q -c 10000 mb3
PING mb3 (169.254.154.74) 10000(10028) bytes of data.
--- mb3 ping statistics ---
10000 packets transmitted, 9857 received, +19 errors, 1% packet loss, time
rtt min/avg/max/mdev = 12.993/17.622/167.841/8.203 ms, pipe 2059, ipg/ewma
I'm expecting lost packets. The errors are the interesting part.
ping -f is supposed to send 100 packets per second or more if the answers get
back sooner. The time says 14 ms per packets so it's obviously rounding up
the sleep time a bit. If I did the math right, that works out to 10
megabits/second, 5 each direction. So the wire is close to saturated if the
tests above are valid.
These are my opinions, not necessarily my employer's. I hate spam.
More information about the Devel