This month, I bought a new 450MHz Pentium II computer for my desktop. The system's arrival reminded me that no matter what the numbers say, computers don't seem to get much faster with each iteration. The difference in speed between my new computer and my 2-year-old 166MHz Pentium MMX system wasn't as large as I expected. This upgrade wasn't nearly as exciting as the upgrade from a 4.77MHz 8088 to a 6MHz 80286 system years ago. But although the new system wasn't my most exciting computer purchase ever, it taught me a few things.
One thing I learned about is registered Synchronous DRAM (SDRAM). I hadn't run across registered RAM before I purchased this machine. The word registered refers to an extra register that vendors add to the memory circuits in yet another make-the-RAM-a-bit-faster scheme. Registered SDRAM is a little more expensive than nonregistered SDRAM, and (surprise!) you need a special motherboard to reap registered SDRAM's benefits.
The new system also has an unusual Error-Correcting Code (ECC) RAM scheme. Don't confuse memory's error-correcting capability with the parity-checking capability that PCs have had since 1981. RAM parity checking incorporates extra hardware on each memory module and the motherboard to detect failures in memory circuits. If faulty silicon in the RAM chip alters a bit's value, the parity circuitry detects the problem. The downside of parity checking is that it can't correct the problems it detects. Most computers respond to parity errors their RAM detects by freezing up, a cure that is often worse than the error that initiated the lockup.
Most computer vendors stopped using parity RAM in the early 1990s because the parity-checking circuitry cost them more than nonparity RAM and generated tons of calls to their Help desks. Memory ads began to differentiate between parity and nonparity RAM. Most consumers didn't understand what parity RAM was, and by 1994, most people opted for nonparity RAM.
This trend troubled me, because parity RAM became less common just as Windows NT appeared. Experience with OS/2 taught me that many of that OS's mysterious system failures and apparent instabilities were nothing more than undiagnosed RAM errors. I got into the habit of running time-consuming memory diagnostic programs on systems before installing OS/2, and I've continued that practice with NT. Several of my clients have grumbled about how buggy NT is, only to discover that the bugs are in their memory modules. I use TouchStone Software's CheckIt and Diagsoft's QAPlus memory testers. (Both products are DOS-based, so you'll need a bootable disk to use them on an NT system.)
ECC makes running memory tests a waste of time. Just as vendors can add a bit of hardware to a RAM module to detect errors, they can add a bit more hardware to correct errors. The result, ECC memory, introduces enough redundancy for the RAM module to correct an erroneous value.
ECC memory is nothing new; it's been around for high-end servers, minicomputers, and mainframes for a long time. But ECC RAM used to be expensive. I saw a Compaq server with ECC 8 years ago, but the system cost more than some minicomputers I've seen. However, a couple of years ago ECC prices fell. Because of the data width of Pentium Pro, Xeon, Pentium II, and Celeron systems and because of some extra circuitry on the Intel Pentium II motherboard chipset, ECC became a freebie. The only catch to this price reduction is that you have to buy parity rather than nonparity memory to use ECC. For most clone motherboards, all you need to do to activate ECC is plop some parity memory into the computer and tell the computer to do ECC. You tell the computer to do ECC in its BIOS, often in the Advanced Chipset section. For the past couple of clones I've bought, I've purchased parity memory and set up the machines for ECC. I like knowing that ECC keeps me safe from the occasional RAM glitch. The peace-of-mind payoff that running ECC RAM provides is well worth the cost and effort of setting up a machine to do ECC.
I installed parity RAM on my new computer so that I could set it up to do ECC. The machine's 450MHz processor uses an external 100MHz bus rather than the 66MHz bus that most Intel chips have used over the past few years. Because the CPU's external speed is faster, I needed faster RAM than the memory I've been buying for my other machines. After I bought the system, I shopped around for good prices on 128MB SDRAM that can work at 100MHz. The RAM choices I found surprised me. As far as I can tell, the only 100MHz SDRAM available is parity. I couldn't find any nonparity.
I purchased parity SDRAM, inserted the memory, started the computer, and dug into the BIOS setup program, intending to find and turn on ECC. I discovered that the AOpen motherboard's ECC choices weren't on and off but off and auto. "Nice," I thought. "I don't even need to know what kind of memory I install. The system will do ECC if it finds ECC RAM but will still function if it doesn't find ECC RAM." However, I was stunned to find that when I looked at the BIOS a second time, its default ECC value was off. I changed it to auto without a problem, but this default ECC value proved to me that computer vendors are still dumb.
Finally, the new computer gave me a chance to experiment with Windows 2000 (Win2K) beta 3. I received an early version of beta 3 at the same time as the new system. After all the trouble I had with NT 5.0 Beta 2, I was eager to give the new beta a whirl. (For a description of my problems with Beta 2, see "Adventures with Beta 2," December 1998.) The new beta pleasantly surprised me.
Drivers for my new computer's Matrox Millennium G200 video card and my Epson, Kodak, and Agfa digital cameras come on the beta 3 CD-ROM. Beta 3 detected and loaded a driver for my Intel videoconferencing camera, and NetMeeting showed that Win2K can handle the camera's output. Beta 3's mouse driver includes support for Microsoft's IntelliMouse wheel, and I found that getting rid of Acid Desktop (oops, sorry—I meant Active Desktop) is far simpler in beta 3 than in Windows 98.
Beta 3 also includes some little touches that I like a lot. For example, it eliminates an annoying Windows habit that you've probably noticed if you've ever clicked Have Disk when you're loading a driver that you've saved to your hard disk. NT 4.0 and earlier and Win9x insist on spinning the disk drive for 30 seconds before letting you tell them that the driver is on your hard disk. Win2K beta 3 gives you a pick-a-directory dialog box as soon as you select Have Disk, without putting you through the jarring empty-drive sound.
Nevertheless, I had a couple of problems installing beta 3. My new computer came with Creative Technology's PCI-based Sound Blaster PCI128 sound card. Beta 3 didn't properly detect the sound card, but the card worked fine with its NT 4.0 driver despite a number of dire warnings. I haven't been able to get my miroVIDEO DV300 IEEE 1394 board from Pinnacle Systems to work under Win2K, but I'm not sure that's a problem with the beta; many people have trouble getting the card to work under NT 4.0.
One Win2K wart really stuck out in my beta 3 testing: reboots. Win2K reboots are slow. They will probably be faster in the OS's final release, but they might not be any less frequent than in the beta version. Despite promises from Jim Allchin (senior vice president of Microsoft's Personal and Business Systems Group) that Win2K would boot less frequently, beta 3 requires almost as many reboots as NT 4.0 requires. If you change the screen font, you reboot. If you load many print drivers, you reboot. If you mess with the system's network settings, you reboot. I thought all this rebooting was going away. Maybe it will in beta 4.