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.
