The other side of the moon

To run perl code without executing any END blocks, put this at the end of your program:

   exec('true');

You'd put that in place of any exit() statement as well. I'll leave it to you to figure out return values. It's not that hard.

So, why did I need this?

I have this large program in perl, and it has a module that prints out a bunch of stats in the END block. This is all fine for the default use case, but today I needed to write another small program that does a bunch of auditing on this module - something like a unit test, but not exactly.

Anyway, this smaller program only needed the module to initialise, but not actually execute, and it doesn't require the stats at the end of the code to be printed either, so I needed to figure out how to run a program without executing the END block.

I looked up the perlmod doc, and it said that the only conditions under which END is not executed is if the process is replaced using exec or you're thrown out of the water by a signal. Voilà, no more END.

For the last few weeks, I've been running a Mac Book Pro (Mac OS X 10.4.11) and Ubuntu Linux 8.10 on an IBM Thinkpad T60p. I generally have both on at the same time, and connected to the same wireless router. I also have both boxes reasonably close to each other since I'd rather not have to physically move in order to switch.

This set up limits any differences in network connectivity to the laptops themselves. Either the hardware or the software running on it. (Though there is an insignificant, but non-zero probability that a thin channel of ionized air exists between one laptop and the router and not the other, but we'll neglect this possibility for now).

In both cases, I have the laptops set up to automatically connect to the network, but have also tried manual connects. I've tested this with the network configured with WEP security and also no security. I did not use WPA because there are known problems with NetworkManager on Ubuntu and WPA networks. My results did not differ with the two networks, so for the rest of this post, assume either.

Time to connect

The Mac consistently connects to the network much faster than Ubuntu does, and by a very large margin. I've tried connecting the Mac first and Ubuntu second, and vice-versa with no noticeable difference.

The Mac connects in a few seconds, slightly longer for WEP than for an unsecured network, but it's always a matter of seconds.

Ubuntu on the other hand takes anywhere from 40 seconds to a few minutes to connect, and on several occassions fails to connect at the first attempt. On system boot up, it takes 3-4 minutes to connect to the network. I've tested this with NetworkManager, Wicd and simply using iwconfig and dhclient on the command line. There is negligible difference in the three methods.

Connection speed

Again the Mac wins. While I haven't measured actual connection speeds, I just inspect how fast DNS lookups take and how fast a given file downloads over HTTP on the two systems at the same time. This time the difference is not an order of magnitude, but is still significant. Ubuntu can take 10-20% more time to download the same file, however at times it will just fail the DNS lookup. This could, however be related to the third item I looked at.

Packet loss

The Ubuntu box frequently ranges between 30-50% packet loss between the laptop and the wireless router, sometimes jumping up to 80% packet loss. The Mac on the other hand had no packet loss.

I haven't been very scientific in my measurements, and I don't yet know whether the problems I see with the Ubuntu/Thinkpad box are hardware or software related. However, for a while, I had Windows XP on an Acer, which also had problems connecting to the network, but did not experience the same kinds of packet loss that the Ubuntu box has.

If anyone has pointers on what I should be looking at, please leave a comment, and I'll update this post with my findings.