Hi,

I suspect my system is showing wrong CPU speed in /proc/cpuinfo. All kind of tools like hwinfo or dmidecode rely on the same sources, so they also not report the true speed. I did some CPU benchmarking and I see lower results compared to other more or less equal systems. I wonder if there is a simple script or program that calculates the actual clockspeed of the (single core) processor. It doesn't have to be very accurate. I do not have a graphical environment, so it should be run from the CLI. I run latest debian 486 on older native 32 bit hardware (K6-III+). Any ideas?

Thanks,

Mike.

Why ...? Have you checked the Manufacturers website for the Specs for your Motherboard/CPU chip(s)?

Note that you'll never see that level of performance, because there is always some overhead of the OS, not to mention that shell scripts are interpreted ie (re-)parsed line by line each time each line is run.
You could try a C program using a high resolution timer lib, and even run that prog in real-time mode, but there'll likely still be a small difference.

Would be nice to see some actual data:
1. Which CPU exactly?
2. Which settings in the BIOS?
3. What is reported from your tools?
4. Which benchmarks, compared to which machines, with which results?

Hi Guys,

Thanks for the reply. The system is an older super socket 7 system (don't laugh at me ;-) ) with the following specs:

Mobo: ASUS TX97-e
processor: K6-III+ 400ATZ
mem: 256MB SDRAM
FSB: 66MHz
jumper: 6x (no multiplier settings in bios)
cpu frequency: 6x66 = 400MHz
OS: Debian
Kernel: 2.6.32-5-486

The problem is with the cpu frequency scaling (for K6-III+ this is powernowd). Powernowd is able to change the multiplier to the K6-III+ on the fly to change the speed in steps of 33MHz (66x2, 66x2.5, 66x3 ... 66x6) etc. However, the following happens:

If I boot the system without powernowd the system is 400MHz and if I do a simple synthetic benchmark I get ~410000 Dhrystones. If I boot the system with powernowd enabled it shows 178MHz when idle. 178 MHz is a strange value to me because the scaling should be in steps of 33MHz, expecting 133, 166, 200, 233, 266, 300, 333, 366 and 400.

# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 13
model name : AMD-K6(tm)-III Processor
stepping : 0
cpu MHz : 178.180
cache size : 256 KB

If I then do the same benchmark test (cpu 100% full load), /proc/cpuinfo shows 400MHz too, but I got only ~315000 Dhrystones, which suggests a speed of approx 300 MHz.

# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 13
model name : AMD-K6(tm)-III Processor
stepping : 0
cpu MHz : 400.905
cache size : 256 KB

So the frequency scaling is working, but I believe it is calculated on a wrong base FSB and applies the wrong multiplier.

The CPUinfo is fine but frequency scaling gives more latency for example when the cpu is waiting for io frequency scaling kicks in.

That's why the different governors where developed on-demand and performance. If performance was equal there would be no need for different governors.

Even if I leave the benchmark run for over 20 minutes? After about 5 seconds of 100% cpu load, the processor is scaled to 400MHz, so the latency is not that high, and should not have such a big hit on the final outcome. And this is exactly why I would like to have a program which can tell me the true processor speed instead of trusting what /proc/cpuinfo says ;-)

Yes even if you let the benchmark run for 20 minutes frequency scaling lowers energy consumption but comes at the price of lower performance.

I don't really believe that. While the processor is under 100% load the processor is running at full 400MHz all the time. So there is no slow down by frequency scaling during a dhrystone benchmark. But my initial question was if someone is aware of a simple program that can calculate cpu speed.

This information is available in sysfs. In particular, check out scaling_cur_freq and cpuinfo_cur_freq in /sys/devices/system/cpu/cpu*/cpufreq.

@idle:

# cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
178180
# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
178180


@100% load:

# cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
400905
# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
400905

But this is also very interesting:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
400905 356360 178180 267270 311815

It looks like the cpufreqd calculates with steps of 44,5 MHz instead of 33MHz. My FSB is 66, and multipliers of the K6 are 2.0, 2.5, 3.0 ... 6.0. These values above are just wrong, they should be near 133,166,200 ... 400.

I did some research and it seems that powernow does also change the fsb. To be continued.

Maybe this helps in determine what's going on http://www.ibm.com/developerworks/li...y/l-cpufreq-2/.

That is an interesting article for sure. However, on my old board the FSB can not be manipulated through software. The settings are fixed with a jumper on the mainboard and is locked @ 66MHz. Only the multiplier of the K6-III+ can be set dynamically. I did a test by setting the CPU speed to te lowest possible speed (178 MHz). I use the userspace governor, so I can set it that way manually and the processor will not scale up to higher speeds when the cpuload raises to 100%. If I do the benchmark I get a score which suggests 133 MHz, so my multiplier should be 2 (2x66=133MHz). Doing several tests with different speeds and some calculating I came up with the following table:

cpufreq: Actual speed:
178180 = 133 MHz (2x66)
267270 = 200 MHz (3x66)
311815 = 233 MHz (3.5x66)
356360 = 266 MHz (4x66)
400905 = 300 MHz (4.5x66)

Thus I believe cpufreq is actually scaling between 133 and 300 MHz while showing values between 178 and 400 MHz. Where does this go wrong? Can I manipulate cpufreq by parsing any parameters to it? Can I override cpufreq scaling_max_freq?

could you post the output of your drystone test at the different frequencies. That should give a good picture of the actual frequency.