[Linux] Wrong frequency with changed FSB from the bios

[GoogleCodeExporter]

What steps will reproduce the problem?
1. From the bios change the FSB (example 200 -> 240)
2. Start linux with the expected drivers
3. Run turionPC -l

What is the expected output? What do you see instead?
basically if you have:
fsb: 250 MHz * multiplier: 16 = 4000 MHz
then I expect:
...
Power States table:
-- Node: 0 Core 0
core 0 pstate 0 (p0) - En:1 VID:18 FID:14 DID:0.00 Freq:4000 VCore:1.3250
...

but i get:
...
Power States table:
-- Node: 0 Core 0
core 0 pstate 0 (p0) - En:1 VID:18 FID:14 DID:0.00 Freq:2800 VCore:1.3250
...

What version of the product are you using? On what operating system?
0.422a on any linux versión (ubuntu 12.04 x64)

Please provide any additional information below.
maybe if you take the fsb from the "dmidecode --type processor" command-line it 
will be fixed...

Original issue reported on code.google.com by dfox...@gmail.com on 6 Apr 2012 at 2:35

[GoogleCodeExporter]

Well, I think I documented this inside the readme file. Since I have no clues 
on how to retrieve bus frequency asking directly to the processor, the bus 
frequency is assumed to be 200 Mhz (or whatever it is for your specific 
processor). I thought about an option to *manually* set the bus frequency to 
better reflect the actual frequency but I never implemented it.

The option to take the bus frequency from dmidecode is smart, but unfortunately 
it won't work on Windows (since it has no dmidecode), but it could be a way to 
do that automatically in Linux. At the moment asking to the motherboard could 
be the only way to gather the bus frequency, but every motherboard has a 
different interface except for dmi that should be a standard way.

I'll look into this.

Original comment by paolo.sa...@gmail.com on 7 Apr 2012 at 1:55

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

DMI data are not reliable. They are prepped by the BIOS boot-time
and most of the time they are hardcoded.

From a system w/227 reference clock (Supermicro 4p board):

# dmidecode  | grep -C2 200
    Version: D1                                                  
    Voltage: 1.2 V
    External Clock: 200 MHz
    Max Speed: 2500 MHz
    Current Speed: 2500 MHz
--
    Version: D1                                                  
    Voltage: 1.2 V
    External Clock: 200 MHz
    Max Speed: 2500 MHz
    Current Speed: 2500 MHz
--
    Version: D1                                                  
    Voltage: 1.2 V
    External Clock: 200 MHz
    Max Speed: 2500 MHz
    Current Speed: 2500 MHz
--
    Version: D1                                                  
    Voltage: 1.2 V
    External Clock: 200 MHz
    Max Speed: 2500 MHz
    Current Speed: 2500 MHz
# 

There are so many boards out there and requested feature would require
per-board method of retrieving current refclock. This look unmaintainable
given current project's resources

More than that, usability of TPC would take a hit with -set freq. User
would end up needing to use odd frequencies (no more 100-MHz-increments).

I believe that keeping FSB out of TPC is the best way forward. Power users
should be skilled enough to calculate resulting frequency w/o problems,
e.g. 2500*227/200 = 2837.5.

We could also consider replacing frequency with a 100-MHz-base-multiplier
thus relieving TPC completely from frequency reporting. So,

-- Node: 7 Core 5
core 5 pstate 0 (p0) - En:1 VID:29 FID:9 DID:0.00 Freq:2500 VCore:1.1875
core 5 pstate 1 (p1) - En:1 VID:32 FID:6 DID:0.00 Freq:2200 VCore:1.1500
core 5 pstate 2 (p2) - En:1 VID:36 FID:2 DID:0.00 Freq:1800 VCore:1.1000
(...)

would become (for instance):

-- Node: 7 Core 5
core 5 pstate 0 (p0) - En:1 VID:29 FID:9 DID:0.00 Mult:25x VCore:1.1875
core 5 pstate 1 (p1) - En:1 VID:32 FID:6 DID:0.00 Mult:22x VCore:1.1500
core 5 pstate 2 (p2) - En:1 VID:36 FID:2 DID:0.00 Mult:18x VCore:1.1000
(...)

Original comment by kszy...@gmail.com on 24 Jun 2012 at 1:47

[GoogleCodeExporter]

Had some spare cycles -- attached clockspeed.c (proof of concept, x86_64 + 
Linux only).
It determines CPU and refclock frequencies based on TSC/time measurement.

To build -- gcc -D_GNU_SOURCE -O2 -o clockspeed clockspeed.c  -lrt
To run -- make sure that msr module is loaded, then run ./clockspeed as root.

Here's what I get on my machines (AMD 10h and 15h)

$ sudo ./clockspeed
Determining CPU frequency, please wait...
Refclock: 226.990 MHz
Clockspeed: 2837.381 MHz

$ sudo ./clockspeed
Determining CPU frequency, please wait...
Refclock: 200.018 MHz
Clockspeed: 2400.214 MHz

$ sudo ./clockspeed
Determining CPU frequency, please wait...
Refclock: 200.002 MHz
Clockspeed: 3000.026 MHz

It's a proof of concept -- would need add'l work before any integration happens
(no i386 code -- I'm lazy, no Windows support though that could be added easily,
at least from what I see).

Original comment by kszy...@gmail.com on 15 Jul 2012 at 7:20

Attachments:

• clockspeed.c

[GoogleCodeExporter]

Actually I'm not so much interested in this feature, I can calculate my 
frequencies manually. Anyway everywhere in /proc/cpuinfo and in 
/sys/devices/system/cpu/cpu?/cpufreq/scaling_cur_freq there will be always 
frequencies with the default refclock of 200, so maybe it is a good thing to 
keep it consistent with tpc?

But I runned your clockspeed anyway and I think it does not work well with 
boost states at least on my Thuban:

./clockspeed 
Determining CPU frequency, please wait...
Refclock: 169.504 MHz
Clockspeed: 2712.061 MHz

while the boost state is 3200MHz and surely the Refclock is 200 MHz. 
170/2.7*3.2=200

I understood that is difficult to get the real frequency in boost states. The 
only way is using cpufreq-aperf, /proc/cpuinfo and 
/sys/devices/system/cpu/cpu?/cpufreq/scaling_cur_freq is wrongly telling 2700MHz

Output of AMD Turion(tm) II Ultra Dual-Core Mobile M640 is fine:
./clockspeed 
Determining CPU frequency, please wait...
Refclock: 199.492 MHz
Clockspeed: 2593.398 MHz

Output of AMD Turion(tm) II Neo N40L Dual-Core Processor is somehow wrong:
./clockspeed
Determining CPU frequency, please wait...
Refclock: 99.840 MHz
Clockspeed: 1497.593 MHz

clockspeed is correct, but Refclock should be 200MHz, or am I wrong? Maybe you 
missed DID divider?

TurionPowerControl -l
Turion Power States Optimization and Control - by blackshard - v0.43

Main processor is Family 10h Processor
        Family: 0xf             Model: 0x6              Stepping: 0x3
        Extended Family: 0x10   Extended Model: 0x6
        Package Type: 0x4       BrandId: 0x2292 
Machine has 1 nodes
Processor has 2 cores
Processor has 5 p-states
Processor has 0 boost states

Power States table:
-- Node: 0 Core 0
core 0 pstate 0 (p0) - En:1 VID:44 FID:14 DID:1.00 Freq:1500 VCore:1.0000
core 0 pstate 1 (p1) - En:1 VID:47 FID:10 DID:1.00 Freq:1300 VCore:0.9625
core 0 pstate 2 (p2) - En:1 VID:51 FID:4 DID:1.00 Freq:1000 VCore:0.9125
core 0 pstate 3 (p3) - En:1 VID:65 FID:0 DID:2.00 Freq:400 VCore:0.7375
core 0 pstate 4 (p4) - En:0 VID:0 FID:0 DID:0.00 Freq:1600 VCore:1.5500
-- Node: 0 Core 1
core 1 pstate 0 (p0) - En:1 VID:44 FID:14 DID:1.00 Freq:1500 VCore:1.0000
core 1 pstate 1 (p1) - En:1 VID:47 FID:10 DID:1.00 Freq:1300 VCore:0.9625
core 1 pstate 2 (p2) - En:1 VID:51 FID:4 DID:1.00 Freq:1000 VCore:0.9125
core 1 pstate 3 (p3) - En:1 VID:65 FID:0 DID:2.00 Freq:400 VCore:0.7375
core 1 pstate 4 (p4) - En:0 VID:56 FID:0 DID:1.00 Freq:800 VCore:0.8500

 --- Node 0:
Processor Maximum PState: 3
Processor Startup PState: 2
Processor Maximum Operating Frequency: 1500 MHz

Minimum allowed VID: 123 (0.013v) - Maximum allowed VID 44 (1.000v)
Processor AltVID: 65 (0.738v)

Original comment by J.Fi...@gmail.com on 14 Dec 2012 at 2:09

[GoogleCodeExporter]

Yeah, that version had number of deficiencies. These should resolved in the 
attached version... feel free to check it out (on Thuban).

Let know of the results! :)

On the N40L the divider is most likely what's confusing the code... I'll take a 
look.

Original comment by kszy...@gmail.com on 26 Dec 2012 at 5:12

Attachments:

• clockspeed.c

[GoogleCodeExporter]

And here's a version that takes care of the divider and also uses current 
P-state's
frequency for calculations (on CPUs w/o Turbo support).

Original comment by kszy...@gmail.com on 6 May 2013 at 12:04

Attachments:

• clockspeed.c

[GoogleCodeExporter]

And here's yet another version that produces reliable results even when 
PowerNow is disabled.

Original comment by kszy...@gmail.com on 20 Jun 2014 at 1:13

Attachments:

• clockspeed.c