Is my CPU throttling?

[neddie]

I've got a Dell Inspiron 510m running Mandriva LE2005, and I'd like to be able to tell if the CPU is throttling properly. It's got a Centrino 1.6GHz in it so should be able to use quite a range of frequencies depending on load. I read that you can tell by the contents of /proc/cpuinfo but on my machine it seems to always say "cpu MHz : 1598.873", even if it's on battery power and it's not doing anything taxing (at least, I don't _think_ it is!). Clicking on the battery icon just tells me how much time is left on the battery, nothing about the CPU.

 

In lsmod I can see that the modules cpufreq_ondemand, cpufreq_powersave and speedstep-centrino are loaded, and in MCC I can see that the service cpufreq is automatically started at boot - do I need to do anything else?

 

Thanks!

Edited December 21, 2005 by neddie

[arctic]

take a look here. it is basically for acer centrinos but can be used for other laptops as well (i used the commands on my esc lappy). i guess you will find enough information there.

http://www-lehre.inf.uos.de/~rfreund/acpi.php

don't forget to take a look the links at the bottom of the site for cpufrqd and speedfreqd.

happy reading :)

[neddie]

Aha, perfect, thank you.

So it looks like I have ACPI and it is _capable_ of being throttled, but at the moment the only throttling it's doing is based on whether it's plugged in or not. The /proc/cpuinfo seems to be a red herring, but cat /proc/acpi/processor/CPU0/throttling shows what state it's currently in, which for me is 0% (full speed) when plugged in and 25% (3-quarters speed) when on battery. And "echo -n (state number) > throttling" in that directory does indeed speed it up and slow it down.

 

So I guess the next step is to get either cpufreqd or speedfreqd to get the throttling going dynamically...

Edited June 7, 2005 by neddie

[coverup]

cpudyn daemon works for me better than cpufreqd, though I use apm.

[neddie]

So this is the weird thing.

If I run the distributed.net client, I can get a rough idea of how fast the procsesor is running, by running the benchmark and looking at the rates it calculates. I can compare the rates when the processor is in its different states (by for example echo -n 7 > throttling) and the rates really do change, so I'm thinking that this throttling file is an accurate way of telling how fast the processor is running.

Now, I put the state in 0 and watch the battery with no load, and compare it with the same thing in state 7. You'd expect if the processor is running at ~10% of the speed, the battery would last longer, right? Except it is almost _exactly_ the same, no difference _at_all_. I can draw graphs of battery % against time and they are right on top of each other. I'm confused.

Either this throttling file isn't telling me the whole story, and the CPU is really running at some other rate, or this whole throttling thing isn't doing what I think it should at all (like the processor is running full whack whatever the throttling state but it just diverts different percentages of the time to real CPU work). It doesn't matter which of cpufreqd or speedfreq or cpudyn I use if none of them are going to save me battery life.

Any clues?

[coverup]

Don't know that stuff well, but IIRC, battery life depends on how well frequency scaling (speedstepping) works. I think there are only few levels (steps) that Pentium M CPU can be at. So don't expect that reducing load by 10% will aoutomatically mean battery life 10% longer... You can monitor frequency using the gkrellm monitor. In order to get speedstepping to work, you need a CPUFREQ aware kernel, a centrino speedstep module loaded and a daemon running such as cpudyn.

[neddie]

No, not "reducing the load by 10%", but "processor is running at ~10% of the speed". When I do "cat /proc/acpi/processor/CPU0/throttling" it tells me the states, from 0 (no throttling, full speed) to 7 (most throttling, slowest speed). As I said, I've tried this out manually setting the states and seen that these states have a measurable effect on the speed of the dnetc client (from 4 million keys/sec down to around 400 thousand keys/sec - hence ~10% of the speed).

 

IIRC, battery life depends on how well frequency scaling (speedstepping) works

Well yes, that's what I would expect too, but what I said in that last post was that although changing these states has a measurable effect on the dnetc benchmarks, it has absolutely NO effect on the battery life, as far as I can tell.

gkrellm tells me the processor load (0%-5%) but doesn't tell me anything about frequency, at least not that I can find in the config.

[coverup]

I have gkrellm plugins installed, the plugin called gkx86info shows the CPU frequency

[ac_dispatcher]

For some commands:

 

https://mandrivausers.org/index.php?showtopic=17648&hl=

[neddie]

Well I think I've figured it out, so I thought I'd (belatedly) post my findings here.

Firstly, this throttling thing with the 8 steps wasn't doing what I thought it was doing, hence why it had zero effect on the battery life.

Thanks to the gkrellm-plugins hints I was able to get my frequency displayed, and gradually things started to make sense. Turns out my frequency-stepping _was_ working all along, so I was always looking at 600 MHz behaviour, hence why it was always the same. And disabling cpufreqd left it at 600 MHz, hence why that didn't affect it either. By provoking load to bump the frequency up to full 1.6 GHz, and then disabling cpufreqd, I was able to watch what happens at high frequency and zero load, and the battery drained in about 2 hours instead of 3.5 hours. With high load on the hard drive and dvd drive it drained in around an hour.

 

So, bottom line for anyone else who's confused with this, mine was working all along, and I just needed gkrellm and gkrellm-plugins to see what it was doing! The only bad news is that because it was doing this all along I can't squeeze any more life out of my battery...

Thanks all for the help.