The 2.2GHz P4 on Linux and Win-XP

The jury's still out...

  • alert
  • submit to reddit

Choosing a cloud hosting partner with confidence

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

Providing a secure and efficient Helpdesk

More from The Register

next story
Preview redux: Microsoft ships new Windows 10 build with 7,000 changes
Latest bleeding-edge bits borrow Action Center from Windows Phone
Google opens Inbox – email for people too thick to handle email
Print this article out and give it to someone tech-y if you get stuck
Microsoft promises Windows 10 will mean two-factor auth for all
Sneak peek at security features Redmond's baking into new OS
UNIX greybeards threaten Debian fork over systemd plan
'Veteran Unix Admins' fear desktop emphasis is betraying open source
Entity Framework goes 'code first' as Microsoft pulls visual design tool
Visual Studio database diagramming's out the window
Google+ goes TITSUP. But WHO knew? How long? Anyone ... Hello ...
Wobbly Gmail, Contacts, Calendar on the other hand ...
DEATH by PowerPoint: Microsoft warns of 0-day attack hidden in slides
Might put out patch in update, might chuck it out sooner
Redmond top man Satya Nadella: 'Microsoft LOVES Linux'
Open-source 'love' fairly runneth over at cloud event
prev story


Choosing cloud Backup services
Demystify how you can address your data protection needs in your small- to medium-sized business and select the best online backup service to meet your needs.
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.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
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.
Storage capacity and performance optimization at Mizuno USA
Mizuno USA turn to Tegile storage technology to solve both their SAN and backup issues.