The engineers responsible for Intel's Core Duo processor and Centrino Duo platform are a bit frustrated.  Years of hard work leading up to the platform's launch in early January was first plagued by the problem of availability.  Core Duo and Centrino Duo notebooks are still not widely available, and that will continue to be the case at least for another week or two.  Outside of availability, another even more troubling problem crept up - could it be that the Core Duo platform had a bug that significantly reduced battery life when paired with any USB 2.0 device?  The folks at Tom's Hardware originally uncovered the issue, when they noted that battery life on their ASUS Core Duo notebook dropped dramatically after merely connecting an external USB 2.0 device. 

How much more frustrating could things get?  After spending years of work on a new mobile CPU and platform, your customers still really can't buy them and the one thing that everyone remembers about them is that they have some sort of a bug that reduces battery life.  When you've spent a good deal of your design time trying to increase battery life, having a reputation of decreasing it before notebooks are widely available has to be a tough pill to swallow. 

However, the case isn't as open and shut as that; the original test data indicated that this was primarily a Core Duo problem, while Microsoft insists that the problem should affect all notebooks.  The other issue is that, until last week, every single Core Duo platform that we could get our hands on was pre-production.  There's also the question of whether or not the problem is caused by the actual USB device used.  And finally, amongst all of this debate and finger pointing, a temporary solution actually existed, just begging to be tested. 

We set out on investigating this issue immediately after it was discovered, but soon found out that it was a lot more complicated than we thought upon first glance.  We've spent almost the past two weeks performing non-stop battery life testing on five notebooks with up to 4 different USB devices, testing theories, trying to pinpoint exactly what causes this problem and testing Microsoft's fix.  What follows is the process that we went through in our labs when faced with this strange bug.



Starting at the Beginning

It wasn't too long ago that power consumption was hardly discussed, but these days, you can't have a technical discussion about microprocessors without mentioning it as a design consideration.  Mobile CPUs in particular have had to be power-conscious for a pretty long time, thanks to a desire for longer battery life and smaller form factors.  But with power consumption, noise and heat dissipation all becoming major issues on the desktop, we are seeing many mobile technologies make their way into desktop CPUs. 

The primary goal of a mobile CPU is no different than a desktop CPU, and that is to get its work done as quickly as possible.  However, a very important secondary goal of the mobile CPU is to strive to be at the lowest power state possible while getting that work done.  The Dothan core used in the 90nm Pentium M processor had a choice of five operating states:

C0 - full power
C1 - auto halt
C2 - stop clock
C3 - sleep
C4 - deep sleep

As you can guess, the higher the C number, the lower the power consumption.  Switching between these states is completely seamless to the end user because the switching occurs in a number of CPU clocks (nanoseconds).  With each processor generation, the CPU designers attempt, as best as possible, to get the CPU to stay in the lowest C-state more than it could previously.  That means making the processor faster so that it can complete its tasks quicker, and thus get to those lower C states faster than before. 

With Core Duo, Intel introduced a sixth operating state: deep C4, or a deeper sleep state.  Intel made some serious improvements to the core to allow it to not only get to lower C-states more often, but to reduce power even more at these lower C-states.  We talked about this briefly in our series of articles on the Core Duo processor, documenting how Intel not only brought forth a dual core mobile processor, but also optimized the performance and power consumption of each individual core. 

If you ran any mobile CPU in its full power (C0) state constantly, never allowing it to transition to lower states, you would wreak havoc on your notebook's battery life.  While not quite this extreme, the USB 2.0 battery life issue involves a similar concept. 

Microsoft describes the USB 2.0 issue as follows:

"Windows XP SP2 installs a USB 2.0 driver that initializes any connected USB device. However, the USB 2.0 driver leaves the asynchronous scheduler component continuously running. This problem causes continuous instances of memory access that prevent the computer from entering the deeper Advanced Configuration and Power Interface (ACPI) processor idle sleep states. These processor idle sleep states are also known as C states. For example, these include the C3 and C4 states. These sleep states are designed, in part, to save battery power. If an otherwise idle portable computer cannot enter or maintain the processor idle sleep states, the computer uses its battery power more quickly than you expect."

Basically, if you have a USB 2.0 device plugged in to a computer running Windows XP SP2, your processor will not be able to enter lower power states (e.g. C3, C4 or Deep C4 in the case of Core Duo).  The problem is that if a very power-efficient CPU is prevented from going into its C3 or C4 states, then it's consuming a lot more power than it needs to be.  It's particularly bad because the problem could exist just by having any USB 2.0 device plugged in, even if you're not using the device.

Keep in mind that Microsoft's description of the issue does not place the blame on Intel's Core Duo processor, and instead, implies that it would exist on all platforms regardless of CPU.  Later on in this article, we'll attempt to find out whether this is indeed a universal problem or something that only really impacts Core Duo. 

It is also important to note that the problem appears limited to USB 2.0 devices under Windows XP SP2 and not USB 1.x devices or USB 2.0 devices under other operating systems.  There are some USB 2.0 devices that can avoid the problem; in order for a device to be immune to this problem, it must support a power management mode called Selective Suspend, which allows the OS to put the device to sleep until it's needed.  The vast majority of devices don't seem to support Selective Suspend, and although some USB hubs apparently do, we weren't able to get our hands on any in time for this article. 



The Fix

The Microsoft Knowledge Base article that references the USB power drain problem also provides a solution to the problem, a simple registry edit that prevents the USB devices from keeping the processor from moving to lower power states.  The entire text of the KB article was actually anonymously posted in a Slashdot thread, and thus, is now publicly available.  As with any changes to your Windows Registry, be sure to hang onto a backup copy and make any modifications at your own risk:

A Windows XP SP2-based portable computer uses its battery power more quickly than you expect when a USB 2.0 device is connected

View products that this article applies to.

Partner Only Article Article ID : 899179

Last Review : July 12, 2005

Revision : 1.0

Important: This article contains information about how to modify the registry. Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 (https://premier.microsoft.com/kb/256986/) Description of the Microsoft Windows registry


SYMPTOMS

Consider the following scenario. You install Microsoft Windows XP Service Pack 2 (SP2) on a portable computer. Then, you connect a USB 2.0 device to the computer. In this scenario, the computer uses its battery power more quickly than you expect.

CAUSE

Windows XP SP2 installs a USB 2.0 driver that initializes any connected USB device. However, the USB 2.0 driver leaves the asynchronous scheduler component continuously running. This problem causes continuous instances of memory access that prevent the computer from entering the deeper Advanced Configuration and Power Interface (ACPI) processor idle sleep states. These processor idle sleep states are also known as C states. For example, these include the C3 and C4 states. These sleep states are designed, in part, to save battery power. If an otherwise idle portable computer cannot enter or maintain the processor idle sleep states, the computer uses its battery power more quickly than you expect.

RESOLUTION

Warning: Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk. To resolve this problem, add the EnIdleEndpointSupport entry to the USB registry key. To do this, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate, and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\USB
   
   Note: If the USB subkey does not exist, create it. To do this, follow these steps:
   a. Select the Services key. On the Edit menu, point to New, and then click Key.
   b. Type USB in the New Key #1 box to name the new key "USB."
   
   
3. Right-click USB, point to New, and then click DWORD Value.
4. In the New Value #1 box that appears, type EnIdleEndpointSupport, and then press ENTER.
5. Right-click EnIdleEndpointSupport, and then click Modify.
6. In the Value data box, type 1, leave the Hexadecimal option selected, and then click OK.
7. Quit Registry Editor.

STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

APPLIES TO

  Microsoft Windows XP Service Pack 2, when used with:

• Microsoft Windows XP Professional
• Microsoft Windows XP Home Edition

Unfortunately, the solution isn't completely ready for public deployment, as there are apparently still some scenarios where it doesn't fix the problem.  There may be issues with the problem re-appearing after putting your system to sleep, which are presently being worked on.  However, for the majority of situations, this simple registry modification should, in theory, take care of things.  With the solution in hand, and five notebooks to play with, we went to work.



The Notebooks

In order to test this issue thoroughly, we looked at five notebooks:

ASUS W5A (Sonoma/Pentium M)

ASUS W5F (Napa/Core Duo)

Dell Inspiron E1705 (Napa/Core Duo)

Lenovo Thinkpad T60 (Napa/Core Duo)

Lenovo Thinkpad T43 (Sonoma/Pentium M)

The USB Devices

We tested with three USB devices:

Kingston Data Traveler Elite (USB 2.0)

Vantec NexStar 2 External 3.5" Hard Drive Enclosure (USB 2.0)

Not that this device is entirely externally powered

Microsoft Intellimouse Optical Blue (USB 1.0)

The Test

We standardized on Mobile Mark's Reader 2002SE test simply because that test is hardly CPU intensive, giving it a lot of time to spend in lower power states and potentially giving the asynchronous scheduler bug a good chance to impact battery life. 

	ASUS W5F	ASUS W5A	Dell Inspiron E1705	Lenovo Thinkpad T60	Lenovo Thinkpad T43
CPU:	Intel Core Duo T2400 (1.86GHz)	Intel Pentium M 750 (1.86GHz)	Intel Core Duo T2600 (2.16GHz)	Intel Core Duo T2600 (2.16GHz)	Intel Pentium M 780 (2.26GHz)
Chipset:	Intel 945G	Intel 915G	Intel 945G	Intel 945G	Intel 915G
Chipset Drivers:	Intel 7.2.2.1006	Intel 7.2.2.1006	Intel 7.2.2.1006	Intel 7.2.2.1006	Intel 7.2.2.1006
Memory:	1 x 512MB (DDR2-533)	1 x 512MB (DDR2-400)	2 x 512MB (DDR2-667)	2 x 512MB (DDR2-533)	2 x 512MB (DDR2-533)
Graphics:	Intel Integrated 945G Graphics	Intel Integrated 915G Graphics	Intel Integrated 945G Graphics	Intel Integrated 945G Graphics	Intel Integrated 915G Graphics
Video Drivers:	Intel 14.18.2	Intel 14.18.2	Intel 14.18.2	Intel 14.18.2	Intel 14.18.2
Desktop Resolution:	1280 x 768	1280 x 768	1920 x 1200	1400 x 1050	1024 x 768
Battery Capacity:	50 WHr	50 WHr	80 WHr	56 WHr	51 WHr

Problem #1 - Perfmon is Inaccurate

The first hurdle that we had to overcome was actually proving the cause of the bug.  Microsoft states that the continuously running asynchronous scheduler prevents the CPU from entering lower sleep states (e.g. C3, C4, Deep C4 and Deeper C4) when a USB 2.0 device is installed.  In theory, monitoring the % C3 Time counter in Perfmon should show that when the notebook is idle, the CPU spends all of its time in C3, and plugging in any USB 2.0 device should prevent that from happening.  Unfortunately, that isn't the case:

What we're looking at above is a graph of % C3 time, which actually should include C3 and lower power states (e.g. C4, Deep C4 and Deeper C4).  The first vertical line (orange) indicates when the USB 2.0 device, in this case a Kingston Data Traveler Elite, was inserted.  Note that before and after the USB device was installed, the CPU continued to spend most of its time in C3 or lower, indicating that there is no problem.  However, a quick run of Mobile Mark 2005's Reader 2002SE test proved otherwise.  The sheer presence of the USB 2.0 device reduced battery life from 286 minutes down to 235 minutes, a reduction of 17.8%.  A similar impact was seen when using an externally powered device, in this case a 3.5" hard drive enclosure; battery life dropped from 286 minutes down to 245 minutes, a reduction of 14.3%.  Yet despite Mobile Mark's evidence, Perfmon didn't agree. The processor was allegedly in its lower power states regardless of whether or not a USB 2.0 device was present. 

As you can probably guess, Perfmon is inaccurate in this case.  While Perfmon does a fine job of monitoring C3 states for older processors, it fails to handle properly the CPUs we're most interested in: the Pentium M and Core Duo.  Through our talented investigative journalism (read: by asking a question), we found that there is a tool to report accurately the amount of time spent in C3 on modern day Intel processors. Unfortunately, that tool is only available to OEMs, under NDA, for fine tuning their systems.  Luckily, not everyone abides by the NDAs that their company signs, so we managed to get our hands on the tool. 

The tool is actually just an extension for Perfmon made by Intel to measure accurately the amount of time that their CPUs spend in C3 or lower power states.  Our sources tell us that independently measuring C4 and Deep C4 states is impossible without resorting to actually probing signals on the motherboard, but thankfully, that won't be necessary for what we need to do here today.  What we need to confirm is whether or not plugging in a USB 2.0 device prevents the Pentium M and Core Duo from entering C3 or lower power states. 

With the plugin installed, we now have another performance counter in Perfmon; this time, an accurate reflection of time spent in C3 or lower states.  First up, we have Core Duo:

The orange vertical line indicates when we plugged in the USB 2.0 device

The first vertical line (orange) indicates when we plugged in a USB 2.0 device. Once again, it was a Kingston Data Traveler Elite USB 2.0 drive, although other USB devices had a similar effect.  Once we plugged in the USB 2.0 device, the CPU never went back into its lower power states.  As soon as we removed it (the second vertical line), the asynchronous scheduler was unloaded and the CPU could go back into its lower power modes. 

Next, we tried the same test with a USB 1.0 device, in this case a Microsoft Intellimouse Optical Blue mouse:

The orange vertical line indicates when we plugged in the USB 1.0 device

The CPU had no problems going into C3; however, the continuous polling of the mouse meant that the CPU could not go into C3 as often as if the device had not been installed.  This isn't a bug, just a side effect of having a USB device that is constantly polling for activity. 

Now, the real question is whether or not the same problems exist on a previous generation Centrino system. In this case, we have the Lenovo T43 based on the Pentium M/Sonoma platform released approximately a year ago. 

The first test was the same; plug in a USB 2.0 drive:

The orange vertical line indicates when we plugged in the USB 2.0 device

Just as Intel and Microsoft suggested, this does not look like a Core Duo problem and it affects the older Pentium M the same.  Once again, as soon as the USB 2.0 device is removed, everything goes back to normal.

And just to be sure, we also did the USB 1.0/Mouse test:

The orange vertical line indicates when we plugged in the USB 1.0 device

Once again, we have identical results to the Core Duo notebook.  So far, it is looking like this is not a Core Duo problem and indeed a problem that affects all Intel systems at least.  We'd like to test an AMD solution, but we didn't have anything current at the time of publication nor did we have access to the equivalent AMD tool for monitoring their CPU's C3 time. 



Problem #2 - Disabling a USB device doesn't work

If we now know that this problem should affect both Napa (Core Duo) and Sonoma (Pentium M) platforms, why is it that the results that we've seen to date don't support that theory?  While we can only comment on tests that we've run ourselves, we did run into some issues with the ASUS W5F/W5A notebooks, which are quickly becoming popular Napa/Sonoma test platforms. 

The reason that the two ASUS notebooks are nice to use is because they are virtually identical systems, one simply uses a Sonoma motherboard with a Pentium M CPU while the other uses a Napa board with a Core Duo CPU.  In the end, it provides an excellent level playing field for comparing Core Duo to its predecessor. 

The problem is that both ASUS notebooks feature an integrated USB 2.0 camera, which we originally didn't expect to be a problem because we left it disabled and without its drivers installed.  After all, if a device doesn't have its driver initialized, it shouldn't be impacting our test results, correct?  But let's look at the Microsoft KB article a little closer. Under the cause of the problem, the article states that "Windows XP SP2 installs a USB 2.0 driver that initializes any connected USB device."  It sounds like simply connecting a USB 2.0 device, even if you don't load the drivers for it, would still trigger the bug.  But does that mean if you disable the device, the asynchronous scheduler is still running?  There's only one way to find out, so we ran the Mobile Mark test again, this time on a Lenovo T60 with no integrated USB 2.0 devices. We then connected a USB 2.0 device to it, but did not install a driver, as well as tried disabling the device:

Lenovo T60	Nothing Connected	USB 2.0 Device Connected, No Driver Installed	USB Device Disabled
Reader 2002SE Battery Life in Minutes	286	242	235

With a USB 2.0 device (an external TV tuner) connected, but no driver installed, the battery life on our T60 dropped from 286 minutes down to 242, a reduction of 15.3%.  Disabling the device had no effect either, as we recorded a battery life of 235 minutes.  These findings are particularly important because both ASUS notebooks, the Sonoma and the Napa, feature an integrated USB 2.0 camera.  Even without the drivers loaded, short of ripping the camera out of the system, these two notebooks are terrible reference points for the USB power draw issue as both of them exhibit the issue without even plugging in any external devices! 

To confirm, we looked at C3 time once more on both platforms:

The ASUS notebooks never enter C3 or lower power states, even with no external devices connected

Just as we suspected, the CPUs aren't allowed into their lower power states due to the integrated USB 2.0 camera. 

To further confirm, we applied the workaround documented in the Microsoft KB article.  With no external devices connected to either system, their battery life jumped by approximately another hour:

Reader 2002SE Battery Life in Minutes	Nothing Connected	Nothing Connected (MS Fix Applied)
ASUS W5F (Napa/Core Duo)	219	264
ASUS W5A (Sonoma/Pentium M)	204	273

While this means that our battery life tests from our Core Duo notebook article are significantly lower than they should be (we'll be providing a follow-up to that article in the near future), it also means that neither ASUS notebook should be used in pinpointing the cause or effects of this USB problem. 

Adding an external USB 2.0 device to either ASUS notebook does result in an additional drop in battery life, but the initial damage is done by the integrated camera that you can't unplug.  To truly isolate this problem, we'll need two notebooks that don't have any integrated USB 2.0 devices, which is why we turned to the Lenovo Thinkpad T43 and T60. 



Problem #3 - The fix doesn't always work

We've proved the problem exists, confirmed that it affects more than just Core Duo systems, and have posted Microsoft's solution - so why even bother with an article? 

The problem is that the fix isn't exactly perfect yet.  The biggest problem that we've seen thus far is that while applying the fix gives you back the vast majority of your lost battery life, it won't remain active coming out of suspend.  Once you apply the fix, you are set for as long as that key remains in your registry.  However, if you put your notebook into stand-by, and when it comes out of stand-by, the fix will no longer be active.  The only solution at this point is to reboot your system, which causes the registry to be re-read, and the fix will continue to work normally. 

We confirmed this by once again looking at Perfmon with the C3 residence extension:

The first vertical line (orange) indicates the system going into stand-by, and the second vertical line (green) indicates the system coming out of stand-by. Once the system wakes up, it eventually initializes the asynchronous scheduler again and the CPU is no longer able to enter its lower power states.

While the current workaround is better than nothing, it's still not completely resolved.  We still need a real fix from Microsoft. 

The Results

While we've already proved that the bug is platform independent, as well as showcased that the fix does work (somewhat), below we have data to show you the potential impact of the bug and what you gain back by implementing the fix on each of the five notebooks that we tested.

First up is the Napa based ASUS W5F; keep in mind that this platform features an integrated USB 2.0 camera, so the asynchronous scheduler is active even with no external USB devices connected:

ASUS W5F (Napa/Core Duo)	Nothing Connected	USB Drive (USB 2.0)	External HDD (USB 2.0)	Mouse (USB 1.0)
Normal	219	205	214	216
With Fix	264	249	255	250

You can see that the fix gives you back a good deal of your battery life.  Keep in mind that the run-to-run variation of Mobile Mark 2005's Reader 2002SE test can be in the 3 - 5% range, so smaller differences should be ignored. Note the gain in battery life in the Northing Connected and Mouse (USB 1.0) columns. These gains are completely because of the integrated USB 2.0 camera.

While we're on ASUS, let's look at their Sonoma based W5A, also featuring an integrated USB 2.0 camera:

ASUS W5A (Sonoma/Pentium M)	Nothing Connected	USB Drive (USB 2.0)	External HDD (USB 2.0)
Normal	204	199	218
With Fix	273	260	268

As you'd expect, the W5A behaves very similarly to the W5F.  With the default (Nothing Connected) configuration receiving a huge increase in battery life after the fix was applied, you can see why the two ASUS notebooks are not an ideal test platform for measuring the impact of this bug. 

We also tested the Dell Inspiron E1705:

Dell Inspiron E1705 (Napa/Core Duo)	Nothing Connected	USB Drive (USB 2.0)	External HDD (USB 2.0)
Normal	154	130	133
With Fix	155	135	137

Interestingly enough, the E1705 doesn't actually gain all that much battery life from the fix.  We're still working on finding out why this is the case. For what it's worth, the E1705 has an integrated USB 2.0 hub that, like the ASUS systems and their integrated camera, complicates the issue.  A lot of this problem may be up to the aggressiveness of the power management designed by the notebook maker, but we'll be working with Dell on our final review of the E1705 to figure out exactly what's going on here. 

The final pair of notebooks that we compared are the Lenovo T60 and T43, the "cleanest" of the five in that they do not have any integrated USB 2.0 devices.  First up, the T60:

Lenovo T60 (Napa/Core Duo)	Nothing Connected	USB Drive (USB 2.0)	External HDD (USB 2.0)	Mouse (USB 1.0)
Normal	286	235	245	272
With Fix	290	275	289	271

The T60 behaves exactly as you would expect it to, with the notebook getting back virtually all of its battery life when paired with the External HDD with the fix applied.  We don't know why the Inspiron didn't do the same, but since the ASUS and Dell systems both featured integrated USB 2.0 devices, we can't really predict how they are supposed to react. 

The T43 also behaves as expected:

Lenovo T43 (Sonoma/Pentium M)	Nothing Connected	USB Drive (USB 2.0)	External HDD (USB 2.0)	Mouse (USB 1.0)
Normal	276	201	210	263
With Fix	281	270	267	258

Final Words

First of all, it's important to characterize the impact of the USB 2.0 asynchronous scheduler bug on both Core Duo and Pentium M based systems.  Using the Lenovo T60 and T43 as comparison points, we found that without the fix, adding a bus-powered USB device such as a memory stick reduced battery life anywhere from 18 - 28%.  In the case of the T43, a 28% reduction in battery life for simply plugging in a USB 2.0 device is beyond ridiculous.  In the case of both notebooks, applying Microsoft's fix gives you almost all of your battery life back. The only decrease is due to actual power used by the device and any polling that may be happening as a result of the device being installed. 

It is also extremely important that we point out the existence of this bug on all of the platforms that we tested; in other words, this is not exclusively a Core Duo problem.  In fact, in the case of the T60/T43, the Sonoma based T43 actually lost a larger percentage of its battery life due to the asynchronous scheduler bug than the Napa based T60.  We saw the same results with the ASUS notebooks. With only the integrated USB 2.0 camera connected, the ASUS Napa notebook lost 17% of its battery life due to the bug, while the Sonoma based W5A lost 25.5%.  Once again, implying that this is a Core Duo issue alone is simply incorrect; the problem affects Sonoma platforms just as much, if not more, than Core Duo platforms.  Based on the results that we've seen in our perfmon analysis, we tend to believe Microsoft's assessment that the problem would exist on any system that spent any time in C3 or lower power states.

Thankfully, the Microsoft fix does seem to work pretty well. The only downside is that the problem re-appears after bringing your notebook out of stand-by.  Although a simple reboot will fix the problem once more, it's not a practical long term solution.  Unfortunately, we have absolutely no idea when a true fix will be put in place.  Until Microsoft releases a fix, we can only suggest that all notebook users, regardless of your CPU, either implement the temporary fix that we outlined in this article or be very conscious of leaving USB 2.0 devices connected while on battery power.