In order to do a quick performance test against somebody else's program, I was firing packets at it to test how many it was dropping from a quick Perl script. While that was interesting, in that it was dropping a significant number of packets when under high load (probably close to that of production load at certain times of the day), another problem entertained me.

I was trying to introduce some small sleeps into the script to back off the load some more and turned to the Time::HiRes module for its usleep function. The first problem that I noticed was the script, which previously ran in a fraction of a second, now given a 1 s sleep time was taking about 10 seconds to perform 1,000 iterations. Hence 10ms per iteration and a few orders of magnitude more than I expected!

I tried running this on my local host and it ran as expected in a fraction of a second still. Checking the docs for usleep revealed that it will return the actual number of s that it slept for. This gives us the handy snippet:

perl -mTime::HiRes -e '$t+=Time::HiRes::usleep(0) for (1..1000);print ($t/1000); print "\n";'

The catch seems to be that I was running the test on a couple of Xen guests on older kernels. Some stats that I've recorded and got from people:

• Linux 2.6.24, Ubuntu Gutsy, x86_64: 0.85 s


• Linux 2.6.22, Kubuntu Gutsy, i686: 7.121 s


• Linux 2.6.18, Debian Etch, x86_64: 3998.712 s


• Xen (BitFolk), Linux 2.6.18, Debian Etch, i686: 4007.393 s


• Xen (EC2), Linux 2.6.16, Fedora Core 4, i686: 8921.402 s


• Virtual PC, Linux 2.6.22, Ubuntu Gutsy, i686: 9906.802 s

It seems to point at newer kernels being different - probably to do with the kernel ticks. I seem to remember reading about dynamic ticks being present in newer kernels...

At my current location, wireless internet access via Be is available at about 12Mbit/s. However for my desktop which only contains a wired ethernet interface, I've been using my WRT54G (v2) running OpenWRT to connect to the wireless network, which is WPA2 secured.

I got it working eventually, after some careful reading of the OpenWRT wiki to discover exactly which modes and combinations of modes were actually supported by the system. The main issue has been speed - it has been topping out at around 100KB/s. There was no obvious userspace load on the router, though I suspect that being a WPA2 client isn't a configuration the boxes were designed for, so perhaps there are limitations of the hardware. I'd be interested to see if it's limited when running with WPA2 as an AP, or using a different type of encryption as a client.

This evening I switched over to a Belkin F5D7132 configured in "relay" mode. I'd bought this originally to replace or supplement the single AP we use at the Surrey LUG meetings, though didn't actually get round to bringing it in until today's BringABox.

The relay mode just makes it act as a client to another AP, repeating onto its built in AP and bridging to the ethernet port. Didn't take long at all once I'd figured out which IP address it was sitting on (come on Belkin, a bit of paper in the box saying would be nice). Now downloading happily at full speed!