After reading an excellent article written by The How-To Geek debunking some popular tweaking myths, I too became motivated to seek out and debunk a few myths myself. This is the first of many to come, I’m sure.
The myth goes like this:
Microsoft Windows [insert SKU here] only recognizes one processor core, on multi-core platforms, during boot leading to out-of-the-box slow boot times. With a simple tweak, using the msconfig utility bundled with the operating system, you can increase your boot time!
It seems this myth originated from a post Chris Pirillo made in 2007 on his personal blog, commenting on a reader’s video submission, no surprise there. Pirillo’s lack of real technical experience, combined with the power of suggestion (placebo effect), resulted in the myth appearing on his blog, enabling it to proliferate and remain on the intertubes, to this day.
It is with a heavy heart that I inform you that setting this value to equate to the number of processors (incl. cores), regardless of operating system, will result in absolutely no change in boot time. Enabling this option adds a NUMPROC=[value] entry in your boot loader’s configuration (whether it be boot.ini or bcd-based) that sets the maximum number of processors Microsoft Windows will use. I quote from “Available switch options for the Windows XP and the Windows Server 2003 Boot.ini files” (KB833721):
This switch sets the number of processors that Windows will run at startup. With this switch, you can force a multiprocessor system to use only the quantity of processors (number) that you specify. This switch can help you troubleshoot performance problems and defective CPUs.
For a short time during boot, it is true that only one logical processor is being used… but in this short period, systems like the clock and power management are being spun up – a task that doesn’t necessitate more than one processor. For details, I suggest you grab a copy of Windows Internals (currently in its fourth revision). Here’s a relevant snippet from Chapter 5: Startup and Shutdown (page 267):
When control returns to the KiInitializeKernel function on each processor, control proceeds to the Idle loop, which then causes the system thread created in step 4 of the previous process description to begin executing phase 1. (Secondary processors wait to begin their initialization until step 5 of phase 1, described in the following list.) Phase 1 consists of the following steps. The boot splash screen of Windows 2000 systems includes a progress bar, and the steps at which the progress bar on the screen is updated are included in this list:
1. HalInitSystem is called to prepare the system to accept interrupts from devices and to enable interrupts.
2. The boot video driver (\Windows\System32\Bootvid.dll) is called, which in turn displays the Windows startup screen. (On Windows XP and Windows Server 2003 systems, the driver presents the same graphic that Ntldr placed on the screen earlier in the boot.)
3. The power manager’s initialization is called.
4. The system time is initialized (by calling HalQueryRealTimeClock) and then stored as the time the system booted.
5. On a multiprocessor system, the remaining processors are initialized and execution starts.
Die evil myth. Die.
Two days ago, I provided a small snippet of code that redirected users to a deep-within-Microsoft page that allowed users to pull semi-public hotfixes. Well, it was ugly, error prone, didn’t bring in revenue, and worst — wasn’t easy to link to by the media.
Your server crashed. After hours and hours of grueling crash dump analysis, you determine a problem with a Microsoft component. You search online and release a huge sigh of relief after discovering your problem is documented in the Microsoft Support knowledge base and a hotfix is available… but wait.
