If powersave has cpu setting to dynamic it will automatically cut cpu usage when only under light load. If you want it at max all the time, switch to performance.
kungfu schrieb:
> This is what is displayed
>
> Code:
> --------------------
> “CPU Information
> Processor (CPU): AMD Athlon™ 64 X2 Dual Core Processor 6000+
> Speed: 1,000.00 MHz
> Cores: 2
> Temperature: 28°C”
> --------------------
>
> My CPU should actually be a 3Ghz not 1
It displays the speed your CPU is actually running at right now,
not the maximum speed it could run at if necessary. Try giving
it some work and see if the figure rises.
It is not fine it’s a kernel bug (/proc/cpuinfo). I have exact same thing. I think it comes same with x86_amd, or i586 arch media.
Every other OS version, and Windows shows 2.8 GHz, only 11.1-RC1, and 11.1 have shown the suspicious number 1,000 Mhz. It remains at that setting no matter what and the bogomips value there is wrong to. It doesn’t really matter, but it does mean bad data is going into Smolt.
And here’s the workround, to enjoy your processor at full speed, with both cores operating full SMP.
You’ll need to alter your boot command line, by altering the GRUB info for the 11.1 kernel. When the kernel update to fix comes out, you’ll be able to turn CPUFREQ back on for power-saving and cooler running mode.
rob@fir:~> cat /proc/cmdline
root=/dev/System/Root resume=/dev/sdb5 splash=silent showopts vga=0x346 CPUFREQ=no
rob@fir:~> egrep ‘model|cpu|bogo’ /proc/cpuinfo
cpu family : 15
model : 67
model name : AMD Athlon™ 64 X2 Dual Core Processor 5600+
cpu MHz : 2812.692
cpu cores : 2
cpuid level : 1
bogomips : 5625.38
cpu family : 15
model : 67
model name : AMD Athlon™ 64 X2 Dual Core Processor 5600+
cpu MHz : 2812.692
cpu cores : 2
cpuid level : 1
bogomips : 5625.45
fir:/mnt/home/rob #
So add CPUFREQ=no to turn off, the slowness, it really made things noticeably faster for me.
Had some help investingating this to check thanks to Bugzilla.
Bottom line is, the initial hunch I had that it was just reporting issues was correct.
Whilst I have yet to do proper benchmarks to test, performance comparison, subjective test with it enabled, and investigation showed the frequency is not locked. May be my boot with CPUFREQ enabled last night, had background stuff running or something to slow the subjective test and slow it.
So contrary to the Bugzilla bug report, the frequency was not locked on my system, but it is hard to avoid sampling the frequency when it’s not on low.
The fact that cat /proc/cpuinfo shows the slowest frequency and pathetic bogomips, sux.
But I think it’s just the way the kernel reports info that’s wrong, not the actual operation of it.
Though there may be suspicion that ‘going’ slow, rather than being fast and then idle for longer really saves power. The CPU does run cooler with this feature however, so I guess it is a power saver.
I’ve lowered the bug report priority from highest and lowered the severity from Major, until there’s solid evidence of a real performance problem.