Current CPU clock rate is wrong

[GoogleCodeExporter]

What is the expected output? What do you see instead?
- I see that my current clock rate is 2ghz, and max is 2.66ghz.  This is surely 
true in theory.  However:
1. I am on a Mac Pro running bootcamp, and the Apple BIOS emulation does not 
support speedstep for my Core2-based Xeon CPUs.  So they must always run at max 
speed.
2. I have my own tool where I monitor the WIndows7 cycle counts for the entire 
system, and all cores are indeed max'd at 2.66ghz 24/7. ie. Even on a lightly 
loaded system, the Idle process will be consuming > 2ghz * numCores on its own!

I see every other tool making this same mistake.  It just means one cannot 
trust the values from these tools if Speedstep is in fact disabled.  I believe 
you can detect this special case with a Power API call in Win32, where 
"throttle" is shown as disabled.

What version of the product are you using? On what operating system?
Latest, 0.21beta, Win7 x64.

Attached my report log.

Original issue reported on code.google.com by dbrac...@gmail.com on 21 Feb 2011 at 2:20

Attachments:

• OpenHardwareMonitor.Report.txt

[GoogleCodeExporter]

How did you monitor the CPU cycle count? Note that the the Time Stamp Counter 
(TSC) is increasing at a constant rate on your system (only stopped in certain 
C-States), which can be higher than the current CPU clock rate. Only back in 
the old Pentium days the TSC was counting the actual CPU cycles. For details 
see here: http://en.wikipedia.org/wiki/Time_Stamp_Counter 

Are you sure that Speedstep is not enabled in Windows 7?

Original comment by moel.mich on 21 Feb 2011 at 9:30

• Changed state: NeedsInfo

[GoogleCodeExporter]

Speedstep is disabled on most Mac computers running Windows, b/c Macs have an 
EFI bios.  They emulate the PC BIOS, but not fully.  It's a well known issue.  
So it's guaranteed that my machine is running at full clock rate.  But this 
isn't a mac-only issue.  If you disable Speedstep in a native PC bios, the same 
issue will be witnessed.  Try it out on your computer.

I measure the CPU cycle count via the Vista APIs to query process counts.  It 
is very accurate and requires no kernel mode driver.  This method is also way 
more accurate than the CPU usage #s most tools display.  For example, most apps 
show 0% usage in Task Manager or Process Explorer, but they're just going idle 
before the time tick (15.625ms) is up.  Great way to hide that your app 
actually consumes cycles.  In reality I see a good 10+ processes active while 
my system is "idle" at 0% usage.

Original comment by dbrac...@gmail.com on 21 Feb 2011 at 3:11

[GoogleCodeExporter]

I just tried it on my Core 2 Duo / Windows 7 system. Disabled the CPU EIST 
Function in the BIOS, but the multiplier still drops from 9 to 6 and the clock 
from 3600 to 2400 when the CPU is idle (at least if CPU-Z, OHM are correct). 
Then I disabled also the CPU Enhanced Halt (C1E) in the BIOS, and now the 
multiplier always stays at 9 and the clock at 3600 (again in CPU-Z and OHM). 
From these results I don't see any wrong readings in the Open Hardware Monitor 
(or CPU-Z).

Have you made sure that there is nothing in your Mac system that would control 
the clock dynamically (EIST, C1E, Windows, ... )? So far I haven't seen any 
evidence that your system really runs at the higher clock speed. 

I would guess getting cycle counts from Windows API would get you just the TSC 
frequency (which is always the max clock even when the CPU runs slower).

Original comment by moel.mich on 21 Feb 2011 at 9:45

[GoogleCodeExporter]

When I try my tool on a Core2-based laptop with aggressive power savings, the 
cycle counts do indeed drop from their max, the moment I pull the power cord.  
I believe the Windows cycle counts are thus accurate.

I know of no way to get a Mac Pro to go at lower than max clock rate (2.66ghz). 
 But both OHM and CPU-Z report that it periodically drops down to 2Ghz.  I 
don't believe it ever truly clocks down, however.  Windows reports max cycle 
rate the entire time.

Vista is a cycle accurate scheduler, not sure how they do it, whether they read 
the TSC or what.

Original comment by dbrac...@gmail.com on 21 Feb 2011 at 10:46

[GoogleCodeExporter]

On Core 2 CPUs the TSC is running at a constant frequency, but it is not 
running nonstop. On laptops that go into a deeper halted state when idle, the 
TSC is stopped also. A drop in counts you see there is not caused by a lower 
frequency, but by stopping the CPU and TSC from time to time (when idle).

Original comment by moel.mich on 22 Feb 2011 at 7:28

[GoogleCodeExporter]

Apologies, I believe you're right; from Wikipedia: "Recent Intel processors 
include a constant rate TSC ... With these processors the TSC reads at the 
processor's maximum rate regardless of the actual CPU running rate. "

So if the TSC is fixed at 2.66ghz, I suppose it ticks twice as fast when the 
true clock rate is only 1.33ghz, making processes appear to consume "twice the 
# of cycles" when running at half clock speed.  This is still much more 
accurate than sampling CPU usage only at the 15.625ms tick, however, it cannot 
be trusted to reflect the true HW clock rate.

Now if speedstep is kicking in (not the CPU halt feature), I should see total 
CPU clock cycles consumed rise by ~25% when it does.  Since idle usage uses so 
few clocks as it is (2-3%), it would be difficult to detect this with the naked 
eye.  

Original comment by dbrac...@gmail.com on 22 Feb 2011 at 3:25

[GoogleCodeExporter]

Also note that the multipliers can be changed (by Speedstep or similar 
functions) at a very high rate. So it can be that when the CPU is mostly idle, 
it still switches to a higher multiplier for the short moments when there is 
work.

About CPU usage accuracy: Right now I just use the values from the operating 
system. That is easy to implement in a robust way, and it is consistent with 
the Task Manager values. 

I will close the issue for now, as there is no evidence that the current 
implementation yields wrong results in this case.

Original comment by moel.mich on 22 Feb 2011 at 4:37

• Changed state: Invalid