Intel Core Duo USB Issue: A Mischaracterized Bug
by Anand Lal Shimpi on February 13, 2006 1:40 PM EST- Posted in
- Laptops
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:
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:
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.
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 powerAs 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.
C1 - auto halt
C2 - stop clock
C3 - sleep
C4 - deep sleep
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.
Facebook
Twitter
RSS
61 Comments
View All Comments
Anand Lal Shimpi - Monday, February 13, 2006 - link
It's not a refusal to test, we're simply not sent any for review :) My next article will be a look at Core Duo vs. Turion performance on the desktop, but I'm still working on securing notebook review units. I would like to see if this issue does impact AMD systems as well, and to what degree.After the Core Duo vs. Turion piece, if we still haven't gotten a Turion notebook in house I'll just buy one for this comparison.
Take care,
Anand
havokprod - Monday, February 13, 2006 - link
Does this problem surface with SP1??DigitalFreak - Monday, February 13, 2006 - link
Microsoft has supposedly known about this since at least July 2005. WTF? Why hasn't this been fixed yet?scavio - Monday, February 13, 2006 - link
It must have been difficult to mention and actually link to Tom's, I'm glad to see professionalism still lives.Very nice job on the article, it looks as though you guys went the extra mile and actually did the work to try figure out what was going on. I read the Tom's article a couple of weeks ago and although they uncovered an important issue they seemed to think they could try to get to the bottom of it with phone calls rather than getting their hands dirty and taking the time to test things themselves.
hergieburbur - Tuesday, February 14, 2006 - link
While the technical aspects of this article are intriging, I think there is too much editorial opinion added on top of that.I think the main reason they post the link to Toms is to dispute the claim Tom's supposedly made that this was a Core Duo issue. That is not what the original article stated, though several times in this article there are thinly veiled allusions to that supposed claim.
I think that tech sites should spend a little more time focusing on themselves and the products they review, and a little less trying to show how they are better than the rest. That goes for all sites. You work speaks for itself.
Anand Lal Shimpi - Tuesday, February 14, 2006 - link
The reason for linking the THG article was to avoid taking credit for a discovery that I did not make. They were the first to stumble upon the issue and it was their article that inspired a deeper investigation, which eventually resulted in this article.The point of this article wasn't to show how we were somehow better, but to address the mischaracterization of the problem. The THG results show a tremendous penalty on their Core Duo notebook due to the issue but a relatively small penalty on their Sonoma platform; this article was designed to explain why that was and hopefully clear up the very common misconception that this is predominantly a Core Duo problem.
The problem is that lots of people linked to that first article, and a very large number of those links incorrectly referred to the problem as a Core Duo issue based on the results that were originally presented. In reality, this problem appears to be nothing more than a Microsoft issue that impacts both Core Duo and Pentium M systems (I'm trying to figure out if it impacts Turion systems as well) but it was grossly mischaracterized in its public acception. I don't really care whose fault that is (personally I believe it's the fault of those who linked to the original article without thoroughly reading it), but I do care that the right information gets out there, which is what this article was designed to do.
I learned long ago that the best you can do is to put your best foot forward and let the reader decide on their own how they feel about you. I'm not trying to shape anyone's view of another site through my work, I'm just trying to get the most accurate information out there.
Take care,
Anand
DigitalFreak - Monday, February 13, 2006 - link
That's why Tomshardware sucks and Anandtech doesn't. That and other things *cough*bias *cough*.Anand Lal Shimpi - Monday, February 13, 2006 - link
Be nice guys, if it weren't for the original THG article it would've taken much longer for this investigation to even happen. I just wanted to make sure that the bug was properly characertized and even more importantly, I want to actually see a fully functional fix from Microsoft that works even out of standby.Take care,
Anand
Zebo - Monday, February 13, 2006 - link
Careful back in the day TOMs revealed many of intels buggy hardware (i820, MTH, crashing dualcores ...)bupkus - Monday, February 13, 2006 - link
Look, I just read the intro and the conclusion, and I don't even own a laptop, but...[see subject], I do have an external hard drive and plans to get a laptop.