Intel Core Duo USB Issue: A Mischaracterized Bug
by Anand Lal Shimpi on February 13, 2006 1:40 PM EST- Posted in
- Laptops
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:
Next, we tried the same test with a USB 1.0 device, in this case a Microsoft Intellimouse Optical Blue mouse:
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:
And just to be sure, we also did the USB 1.0/Mouse test:
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
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
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
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
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.