Real World Computing
Is fast the new slow?
Apples and Leopards
My second example might seem rather esoteric, but we've been reading the tea leaves here over the last year or so, and we get the idea that more and more of you out there are dabbling in the world of Macintosh. So my second example of fast being the new slow comes entirely from planet Apple. In this case, I'd dug out a copy of OS X Server - not the current one, but the preceding release - because I wanted to be able to talk sensibly about the new release, Leopard Server, which contains a variety of stunning new ideas, including the Time Machine for doing day-by-day rollbacks and restores.
To carry out a proper appraisal of Leopard, I needed to compare it directly against the older version, which actually turned out to be pretty good. A few neat utilities comprise the Server Management Suite and there's a built-in VNC for remote control, even from a PC, along with point-and-click membership of a Windows Domain (it looks up your user credentials on a reachable Domain Controller). But, most interestingly, it can easily be purchased in a version that comes without any user-count restriction, so in theory you can have an unlimited number of users on your OS X server, which is appealing in many ways.
So I was minded to try out OS X Server on a test platform that involved decommissioning my old Mac mini, upgrading it with a hard drive somewhat above the comic speed rating of the original unit, then installing the server product. As an added bonus, I put together a 320GB external drive in a neat matching enclosure, which came with a FireWire connection to the main unit.
Copying to this file server from several different generations of Macintosh wasn't uplifting. It has gigabit ethernet, as did all the boxes I tested it from, including a current-generation Mac Pro with a four-core CPU and 8GB of RAM, but its performance remained of the same order with all of them. Hit that FireWire-connected, network-shared drive with a copy process containing more than a thousand files (the largest tree of material I hit it with was a 17,000-file backup of my Applications directory) and this supposedly state-of-the-art kit would creep along at roughly three files every second, almost irrespective of the file sizes (although Apples do tend to hide very large numbers of small files, as does Unix, inside pretty graphical representations).
The reason for this dire performance boiled down to something very simple: namely, the support chipset that runs the FireWire interface inside the auxiliary drive enclosure. This chipset tries to pose as a complete PC to the IDE drive plugged into one side of it, while fielding FireWire I/O and disk-access requests from the other side. However, it's lamentably short of brainpower for such an impersonation - it contains no local memory worth mentioning and not much CPU horsepower - so that whenever it's given a new file it first flings the drive heads off in one direction to write the file's directory table entry, then flings them in another direction to write the data. Given the long work queue I was pushing at it, this server and drive chipset combination just couldn't push the data onto the drive platters any faster than the slowest machine I could find in my junk pile (which was an Apricot 266 for anyone who's keeping score).
I know what you're thinking right now - you think I must have a broken network switch. Naturally, I checked this possibility by performing some other tests involving the same switch, which only reinforced my observations. The first test I've already mentioned above, which is that using that Vista ThinkPad (now de-Nortoned and with enough memory) and the same copy operation aimed at the Mac Pro in a server role, I was getting 31MB/sec sustained copy operations through the same switch. Using various PC servers and other machines not running Vista, I could move at a little more than that through the switch.
