Whether Intel's new 0.13-micron Northwood P4 is a good buy for Linux or Windows users I won't be able to say until I compare it to a similar high-end system by AMD later this week; but for now I can definitely say that, paired with the 850 mobo and 512M RDRAM, it's fast on both operating systems, if not spectacularly reliable.

On re-boots, regardless of which OS I'd been using at the time, and on cold startups into both the Windows and Linux HDDs installed singly, I've experienced intermittent boot failures. There's no error message, no POST panic. The thing just sits there quietly with a blank screen every now and again. A subsequent cold boot usually meets with success; but on a few occasions it's happened twice on successive attempts, though never more than that. All CMOS parameters are set to Intel's defaults. I'm not using SCSI, RAID, USB or any BIOS-dependent boot device like a PCI disk adapter, so this is a bit of a puzzler, and a bit of a disappointment.

Good kernel, good drivers

Because Intel provides special chipset drivers and something called an Application Accelerator for Windows users, I was curious to see if Linux would exploit the Northwood's considerable horsepower as well as Windows. The Linux kernel does by nature make better use of the CPU than Windows; the question for me was whether the 'system' -- that is, the CPU, chipset and system memory -- might work together better on Windows as a result of Intel's extra software engineering on its behalf.

To test this, I tried one standard benchmark, the results of which are posted here, and a number of what strike me as common-sense comparisons of everyday tasks.

The kit in question is an Intel D850MVSE mobo with a 2.2GHz Northwood P4; 512M PC800 RDRAM; an Nvidia GeForce AGP4 64M DDR; two Maxtor D740X 20G ATA-133 drives on the mobo's onboard ATA-100 controller, one booting Win-XP Pro and one booting SuSE 7.3 Pro.

I'm using Win-XP on FAT and SuSE on ReiserFS, both installed clean and subsequently patched. Windows is patched with whatever the MS auto-update process does to it and Linux is patched to kernel 2.4.17. The paging files on both disks are 500MB.

First I tried comparing the performance of the Gimp on Linux and Windows immediately after a re-boot. It took the application 3.5 seconds to launch (i.e., for the hourglass to disappear) in Windows and 2.5 seconds in Linux. The second launch, done immediately after to take advantage of RAM caching, took 2 seconds in Windows and 1.2 seconds in Linux.

Displaying a .bmp file 3,177kb in size with the Gimp took 1 second in Windows and 0.8 seconds in Linux, and converting that file to .jpg took 1 second in Windows and 0.6 seconds in Linux.

Launching Mozilla, with a DSL connection already established and my home page (theregister.com) already stored in the browser's cache, took 4.5 seconds in Windows and 5.0 seconds in Linux immediately after a re-boot. A second launch leveraging the RAM cache took 2.5 seconds in Windows and 2.5 seconds in Linux. 'Launching' meant that the home page was fully displayed.

(Interestingly, Internet Explorer takes only 2.5 seconds to launch and load my home page in Windows following a re-boot, but I'm told that MS partially pre-loads it during the Windows system boot to produce the illusion that it's faster than other browsers. I've found that IE and Mozilla are indistinguishable on Windows except for the initial startup time, so I'm willing to believe this is possible.)

On Windows I was able to display a directory of 778MB containing 10,174 files in 0.6 seconds using Windows Explorer. The same directory copied to the Linux drive took 3.2 seconds to display in Krusader (the fastest GUI file browser I know of for Linux). The files were displayed in 'detailed list' mode in both cases.

Copying that directory to another location on the same disk took 3 minutes, 13 seconds in Windows and 3 minutes, 51 seconds in Linux, using the GUI file browsers.

Displaying the contents of the directory with the Bash shell in Linux (ls -al) took 2.5 seconds the first time, and 0.7 seconds the second time with the benefit of RAM caching. Displaying the same directory with the DOS shell in Windows (dir) took 4.5 seconds the first time and 4.5 seconds the second time.

Copying the directory took 3 minutes, 57 seconds using the Bash shell (cp -r) and two minutes, three seconds using the DOS shell (copy).

So what does this tell us? Not a lot, until we do the same tests with different kit. But I can say cautiously that the overall user experience in Windows is snappy and crisp, and that the cost might well be justified if performance suffers with an equally high-powered setup using an Athlon 2000 and DDR SDRAM.

For Linux I'd be a bit more conservative. This is some expensive equipment we're talking about here, and the overal subjective 'feel' under Linux using KDE and Gnome really didn't strike me as sufficiently improved to justify the investment. We may be able to do as well, or better, with the AMD kit for less money. But that remains to be seen.

Disappointments

Aside from unreliable system startups, the biggest disappointment for me is that no amount of Intel processing power seems capable of making the Konqueror and Nautilus file browsers tolerable to use. Krusader is fine -- a bit slower than Win Explorer, but not so much that you'd get impatient with it. But it lacks features like thumbnail views, which can actually be useful to graphics-oriented users and porno Webmasters negotiating a large directory of images. Thumbnail views for image files are exceptionally speedy under Explorer with this kit, but so maddeningly slow with Konqueror and Nautilus that I didn't even bother to time them.

The kernel recompile also didn't take as much from the 2.2 CPU as I'd hoped. Of course it was faster than with a P3, though not dramatically so. But it's probably the case that system memory has more effect here than transistors and clock speed once you get past a certain point.

So now we have a baseline of sorts. An imperfect one, certainly, since we're comparing the performance of two radically different operating systems on a given platform, which is essentially voodoo no matter how hard you try to keep it 'scientific'. But when we apply it relatively to a different high-end hardware setup, I think it will will offer us a decent basis for picking the system that best suits our OS of choice, and our budgets. So stay tuned. ®

Note: A large number of Reg readers have written to ask why the filesystems Reiser and FAT were used. The reason is simple: for now I'm looking into real-world situations, not optimized ones. Most XP users will be upgrading, so that means FAT since NTFS isn't available in the home edition upgrade. Most if not all recent Linux distros default to ext3 or Reiser, and most new users will accept the default. The best comparison of I/O performance would be between ext2 and NTFS, of course; but that's for a separate item which I'll do in future. --tcg