The 2.2GHz P4 on Linux and Win-XP

The jury's still out...

  • alert
  • submit to reddit

Remote control for virtualized desktops

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.co.uk) 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.


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

Internet Security Threat Report 2014

More from The Register

next story
Be real, Apple: In-app goodie grab games AREN'T FREE – EU
Cupertino stands down after Euro legal threats
Download alert: Nearly ALL top 100 Android, iOS paid apps hacked
Attack of the Clones? Yeah, but much, much scarier – report
You stupid BRICK! PCs running Avast AV can't handle Windows fixes
Fix issued, fingers pointed, forums in flames
Microsoft: Your Linux Docker containers are now OURS to command
New tool lets admins wrangle Linux apps from Windows
Bada-Bing! Mozilla flips Firefox to YAHOO! for search
Microsoft system will be the default for browser in US until 2020
Facebook, working on Facebook at Work, works on Facebook. At Work
You don't want your cat or drunk pics at the office
Soz, web devs: Google snatches its Wallet off the table
Killing off web service in 3 months... but app-happy bonkers are fine
prev story


Why cloud backup?
Combining the latest advancements in disk-based backup with secure, integrated, cloud technologies offer organizations fast and assured recovery of their critical enterprise data.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
How to determine if cloud backup is right for your servers
Two key factors, technical feasibility and TCO economics, that backup and IT operations managers should consider when assessing cloud backup.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Getting ahead of the compliance curve
Learn about new services that make it easy to discover and manage certificates across the enterprise and how to get ahead of the compliance curve.