search

jmeier64 / open-hardware-monitor

Automatically exported from code.google.com/p/open-hardware-monitor
0 stars 0 forks source link

Add detection for higher Intel CPU turbo modes (+2 multi and above) #168

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The maximum CPU speed for my system is never shown as 3.60 GHz when the CPU has 
been running at 3.60 GHz.

Original issue reported on code.google.com by r...@rh-software.com on 10 Feb 2011 at 1:18

Attachments:

GoogleCodeExporter commented 9 years ago 
Can you put a load just on one core to get a stable multiplier of 27 on that 
core for a bit a longer time (like more than 1s)? I am not 100% sure if the 
Open Hardware Monitor just missed the short moments when a core was running at 
27, or if the implementation is wrong in the Open Hardware Monitor. 

Right now the Open Hardware Monitor just reads the multiplier from the MSR 
(IA32_PERF_STATUS) and calculates the current core speed based on the TSC 
multiplier and the current TSC frequency. If there is a better method (and you 
want to share it), I would be interested of course.

Original comment by moel.mich on 10 Feb 2011 at 2:03

GoogleCodeExporter commented 9 years ago 
Even when the CPU is running at x27 IA32_PERF_STATUS will return x26!  What I 
do is check if the current is > max none turbo and when it is use 
IA32_FIXED_CTR1 and IA32_TSC to work out what the actual ratio is.  I do this 
all in my driver in kernel mode. Your code will also need to do 
save/enable/restore of IA32_FIXED_CTR_GLBL and IA32_FIXED_CTR_CTRL. You should 
use the Global\Access_MSR_PERF_GLOBAL_CTRL mutex to interlock access to these 
MSRs with other programs. You will need different code for Sandy Bridge.

Original comment by r...@rh-software.com on 10 Feb 2011 at 2:23

GoogleCodeExporter commented 9 years ago 
Thank you very much for your input. It is good to know that the MSR does not 
pick up the higher turbo modes (although this is a stupid "feature"). 

To use the performance counters in an accurate way it will have to be done in 
kernel mode. And then there is still the potential problem of interference (in 
both directions) with other software accessing them without locking any mutex. 
Outside pure kernel code long time intervals would be required for usable 
results, which would cause even more interference problems. In any case, 
something like this should be added to the kernel code once a new driver is 
written.

Original comment by moel.mich on 10 Feb 2011 at 3:16