Page 1 of 1

phc-intel / read_msr issue

Posted: Thu 15. Jul 2010, 17:26
by gordan
I'm using phc-intel 0.3.2-10 on two laptops running RHEL6b2.

Setting the VIDs seems to work OK, but on one of the laptops, the output of read_msr disagrees with what is reported elsewhere about the current CPU speeds, e.g. in /proc/cpuinfo or /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq.

On my ThinkPad T60 with a T7600 C2D, the readings are all as expected and in agreement with other sources.

However, on my Clevo M860TU with a P9600 C2D, read_msr is always reporting the current FID/VID as what was set as the highest FID/VID combination. For example, the machine is idle, and /proc/cpuinfo is correctly saying the current speed is 800MHz, but read_msr is saying the current and target FIDs are 10, which would make it 2.66GHz. On one CPU it always says current=target FID = 10. On the other CPU it says target FID=6, but current FID is always 10. In both cases, current FID reads as 10, which is clearly wrong.

Also, on the newer C2Ds (P series), it seems the IDA and SLFM are listed by completely unintuitive FIDs. e.g. on my P9600, my phc_fids are:
74 10 8 6 134
74 is IDA, which should be multiplier x10.5 (IIRC), and 134 is SLFM, which is actually x3 multiplier. This should at least be documented.

Finally, for those struggling to identify the VID-voltage link (e.g. for cross-checking between Windows utilities and phc-linuxm here is a table listing the value pairs that apply at least to mobile C2D CPUs (checked on T7600 (65nm) and P9600 (45nm) and they are consistent):

FID Voltage
43 1.2500
42 1.2375
41 1.2250
40 1.2125
39 1.2000
38 1.1875
37 1.1750
36 1.1625
35 1.1500
34 1.1375
33 1.1250
32 1.1125
31 1.1000
30 1.0875
29 1.0750
28 1.0625
27 1.0500
26 1.0375
25 1.0250
24 1.0125
23 1.0000
22 0.9875
21 0.9750
20 0.9625
19 0.9500
18 0.9375
17 0.9250

17 is the lowest I have seen settable on actual CPUs (P9600 in SLFM mode), the highest I have seen is 43 (P9600 in IDA mode). Desktop CPUs seem to use a different translation table but I haven't had a chance to check those yet.

Re: phc-intel / read_msr issue

Posted: Thu 15. Jul 2010, 19:22
by the-fallen

i will investigate this issue and going to fix what you mentioned (about documentation).

Please note that at the moment you run read_msr and your cpufreq governor is set to ondemand it MAY be possible it just switches up to a higher FID for a moment to run read_msr quicker.
But I will review the code to check for possibilities that may cause a wrong display of values.

I would like to expose xour VID-Table in a sticky thread with your permission.

Re: phc-intel / read_msr issue

Posted: Thu 15. Jul 2010, 22:21
by gordan
Sure, by all means, post the table in a separate sticky post. The reason I felt it's worth sharing is because the linking seems to be consistent across all C2D Mobile CPUs I've checked it on. The ranges are different, but where the VID numbers are the same, the voltages are the same. They are also predictable, each +/-1 VID change equates to a +/- 0.0125V change, so you could easily work it out using an equation. The projection is that VID=0 would be 0.7125V.

Of course, C2D is well on the way to being phased out, and Core i class CPUs may well have completely unrelated VID numbers, the same way as the C2 Desktop class CPUs have completely different voltages corresponding to the same VIDs.

On the subject of wrong readings, my governor is set to conservative, rather than ondemand, because it stops the CPU from cranking all the way up on a hair trigger. It's really weird because it seems to work just fine on the T7600, but the P9600 readings are completely non-sensical and don't match up with anything else. If /proc/cpuinfo is saying 800MHz, that means read_msr should be saying FID 134. Perhaps it should thus also be listing minimum/SLFM FID to be 134, rather than 6 (which is the minimum non-SLFM FID). Also for max, it should probably be listing 74 (IDA) rather than 10 (normal max on this CPU). It would make the readings less intuitively obvious, but this could be addressed by documentation, and I think it would be more useful to actually list the real register values, rather than trying to forge some of them in the interest of making things more obvious. If it does end up leading to translating special (IDA, SLFM) FIDs, then at least they should be translated to the expected pattern (i.e. FID=3 for SLFM instead of the literal 134, and FID=10.5 for IDA instead of literal 74). But this then starts to get CPU specific and complicated, I think literals would be better.

Re: phc-intel / read_msr issue

Posted: Thu 15. Jul 2010, 22:31
by gordan
Correction - you were right - my governor was set to ondemand (default) and that was throwing the readings way out. I misspelt the governor name in
FAIL. :(