User avatar
Saijin_Naib
Posts: 10
Joined: Fri May 13, 2016 3:40 pm

Are more CPU states possible than min/max/locked?

Wed May 18, 2016 6:20 pm

Are more CPU states possible than min/max/locked?
I know that currently we have 3 states for the CPU on the Raspberry Pi:
Original Clock Rate
overclock_max
overclock_min

Currently, we're only able to jump between min/max or lock ourselves at a given clockrate.

Is it possible to enable more steps for finer granularity in CPU speed steps? I think that'd be really awesome, and I know I would appreciate it. It'd make my rPi much happier for sure, seeing as currently it jumps between 125MHz and 1000MHz.

ghans
Posts: 7871
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany

Re: Are more CPU states possible than min/max/locked?

Wed May 18, 2016 6:43 pm

Raspbian Linux uses "cpufreq governors" to dynamically adjust
the clockspeed. You should propably read up on the cpufreq
system which is a Linux feature.

http://with-raspberrypi.blogspot.de/201 ... uency.html

ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org

User avatar
rpdom
Posts: 15046
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Are more CPU states possible than min/max/locked?

Wed May 18, 2016 6:51 pm

Further to what ghans said, I think you should look at the "conservative" speed governor.

User avatar
Saijin_Naib
Posts: 10
Joined: Fri May 13, 2016 3:40 pm

Re: Are more CPU states possible than min/max/locked?

Wed May 18, 2016 7:29 pm

I thought I was familiar enough with cpufreq after spending endless hours messing around with it on my various webOS devices trying to top the charts. My go-to was ondemandtcl with custom settings and I even got my Pixi+ to bench higher than a stock clocked Pre2.

With all of that said, I'm quite surprised to learn that apparently Raspbian's ondemand just toggles between min/max states and doesn't step inbetween like I'm used to.

I've set conservative and rebooted (it stuck just fine), but once again, cpufreq is reporting only TWO states, and conservative is simply toggling between the two states.

How do we get MORE states supported than just min/max?

Code: Select all

$ cpufreq-info && vcgencmd measure_temp
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to [email protected], please.
analyzing CPU 0:
  driver: BCM2835 CPUFreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 355 us.
  hardware limits: 125 MHz - 1000 MHz
  available frequency steps: 125 MHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 125 MHz and 1000 MHz.
                  The governor "conservative" may decide which speed to use
                  within this range.
  current CPU frequency is 125 MHz.
  cpufreq stats: 125 MHz:71.01%, 1000 MHz:28.99%  (4)
temp=47.1'C

JimmyN
Posts: 1109
Joined: Wed Mar 18, 2015 7:05 pm
Location: Virginia, USA

Re: Are more CPU states possible than min/max/locked?

Wed May 18, 2016 9:06 pm

Conservative works the same as ondemand, min/max only, it's just more conservative about switching to max, it sets the up_threshold higher. You'd need to use the "userspace" governor if you wanted to scale, every other governor is either min, max, or switches between the two. I played around with the userspace governor some but couldn't get it to work, I don't think the kernel supports frequency scaling.

User avatar
Saijin_Naib
Posts: 10
Joined: Fri May 13, 2016 3:40 pm

Re: Are more CPU states possible than min/max/locked?

Wed May 18, 2016 9:17 pm

JimmyN wrote:Conservative works the same as ondemand, min/max only, it's just more conservative about switching to max, it sets the up_threshold higher. You'd need to use the "userspace" governor if you wanted to scale, every other governor is either min, max, or switches between the two. I played around with the userspace governor some but couldn't get it to work, I don't think the kernel supports frequency scaling.
That's what I'm wondering about. Other devices I've used support frequency scaling with multiple steps. Is there an issue tracker for supporting this in Raspbian? Have others asked? I've done some searching in the forum, but most people seem concerned with maxing out perf, not in supporting more steps in frequency scaling.

Reading the kernel docs on cpufreq, it looks like userspace is just a governor that allows individual programs with UID root to set the CPU speed arbitrarily to a static value. That is not what I'm after.


User avatar
Saijin_Naib
Posts: 10
Joined: Fri May 13, 2016 3:40 pm

Re: Are more CPU states possible than min/max/locked?

Thu May 19, 2016 4:25 pm

Gerd wrote:See
https://github.com/raspberrypi/linux/issues/1335
as a starting point.
It's hardcoded and we have to recompile our own kernel? Fantastic.

Thanks for the info.

Sleep Mode zZ
Posts: 319
Joined: Sun Aug 19, 2012 5:56 am
Location: Finland

Re: Are more CPU states possible than min/max/locked?

Fri May 20, 2016 12:43 am

Saijin_Naib wrote: Is it possible to enable more steps for finer granularity in CPU speed steps? I think that'd be really awesome, and I know I would appreciate it. It'd make my rPi much happier for sure, seeing as currently it jumps between 125MHz and 1000MHz.
Just out of curiosity: How does your rPi show its unhappiness with making those big jumps between the frequencies? Why is it not happy?

User avatar
Saijin_Naib
Posts: 10
Joined: Fri May 13, 2016 3:40 pm

Re: Are more CPU states possible than min/max/locked?

Fri May 20, 2016 6:41 am

Sleep Mode zZ wrote: Just out of curiosity: How does your rPi show its unhappiness with making those big jumps between the frequencies? Why is it not happy?
Aside from how hot it runs despite sitting at 125MHz 99% of the time (I have the rPi B Gen 1 with the linear regulator and other fun electrical gremlins), I've been wanting to see if I can't ease the load on my PSU a bit by having the CPU step down to 75MHz or so and then having a number of steps above that, depending upon what would be stable and what the transition latency reported by cpufreq would be.

Ultimately, I think I'm likely barking up the wrong tree and I should very probably scrap my rPi B Gen 1 and just get a Zero. Not only should that be significantly faster, it should also run a lot cooler and draw a lot less. If nothing else, my tinkering here should translate fairly well to any future rPi units I acquire, so I'm glad to learn what I can.

However, the prospect of recompiling the kernel on my B is quite horrifying, and despite grabbing what I believe to be all the required libs and dependencies on my Xubuntu laptop, I've still not figured out how to cross-compile for another architecture yet. Somehow, I don't think going straight for a kernel on baby's first cross-compile is a good idea.

ghans
Posts: 7871
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany

Re: Are more CPU states possible than min/max/locked?

Fri May 20, 2016 7:21 am

Making the "conservative" governor behave like
"ondemand" in practice is very counter-intuitive ...


ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org

Sleep Mode zZ
Posts: 319
Joined: Sun Aug 19, 2012 5:56 am
Location: Finland

Re: Are more CPU states possible than min/max/locked?

Fri May 20, 2016 12:19 pm

Saijin_Naib wrote:
Sleep Mode zZ wrote: Just out of curiosity: How does your rPi show its unhappiness with making those big jumps between the frequencies? Why is it not happy?
Aside from how hot it runs despite sitting at 125MHz 99% of the time (I have the rPi B Gen 1 with the linear regulator and other fun electrical gremlins), I've been wanting to see if I can't ease the load on my PSU a bit by having the CPU step down to 75MHz or so and then having a number of steps above that, depending upon what would be stable and what the transition latency reported by cpufreq would be.
I also had a B (256MB ram) and do not remember any heat issues. It should be able to handle the heat it generates for a couple of decades - unless it is faulty in some way. How hot does your B run? Maybe put a heat sink on it?

The point about the frequency (and voltage) jumps being stressful for the PSU is interesting. I had not thought about it and do not have the expertise to say if it is a real concern. I would just let the PSU fail and get a new one when it happens. :D Unless your rPi is doing something mission critical... Anyway, if this is a real problem, one solution for this would be to use your rPi with a fixed frequency. Your rPi would lose a bit of speed (or heat up a bit more - depending on the fixed frequency), but so would it also if it would use more frequency steps and/or using the conservative governor.

All later models, with the possible exception of a Pi 3, will have reduced idle power consumption. So if power consumption is the main concern, upgrading to a Zero, a A+, a B+ or even a 2 B might be worthwhile.

User avatar
Saijin_Naib
Posts: 10
Joined: Fri May 13, 2016 3:40 pm

Re: Are more CPU states possible than min/max/locked?

Sat May 21, 2016 12:22 am

ghans wrote:Making the "conservative" governor behave like "ondemand" in practice is very counter-intuitive ...
ghans
Quite so. Also the lack of multiple steps flies in the face of every other machine I've used cpufreq on and is also quite counter-intuitive. Maybe this will be addressed at some point in the future.
Sleep Mode zZ wrote: I also had a B (256MB ram) and do not remember any heat issues. It should be able to handle the heat it generates for a couple of decades - unless it is faulty in some way. How hot does your B run? Maybe put a heat sink on it?

The point about the frequency (and voltage) jumps being stressful for the PSU is interesting. I had not thought about it and do not have the expertise to say if it is a real concern. I would just let the PSU fail and get a new one when it happens. :D Unless your rPi is doing something mission critical... Anyway, if this is a real problem, one solution for this would be to use your rPi with a fixed frequency. Your rPi would lose a bit of speed (or heat up a bit more - depending on the fixed frequency), but so would it also if it would use more frequency steps and/or using the conservative governor.

All later models, with the possible exception of a Pi 3, will have reduced idle power consumption. So if power consumption is the main concern, upgrading to a Zero, a A+, a B+ or even a 2 B might be worthwhile.
My rPi is well within operating specs as it sits around 48C idle, with ambient 22c. I do have multiple aluminum heatsinks on it. I was toying with adding a small fan powered off the GPIO headers, but that'd just result in more heat/stress on the linear regulator which will just exacerbate the heat/energy draw issue. Things get a bit more toasty when my 3.2" WaveShare SpotPear LCD is mounted due to reduced airflow in the case combined with increased load/draw.

Neither do I! All I can tell you is how I observe it behaving when powering my rPi versus other electronics. I can hear it whine ever so slightly and it is constantly warm to the touch when powering my rPi. I do live with electrical engineers, but I'm not sure how motivated to assist they'd be. Besides, I'm just a treehugger to them so oftentimes my questions get brushed aside.

Mission critical? Hardly. However, I think my treefrog appreciates having a sane day/night cycle in his tank now that my rPi is running the show :lol: I can't be trusted to turn the lights on/off reliably.

Yeah, I'm thinking a Zero might be where I'm headed, especially if there ever is a Zero+ or something similar with integrated Wi-Fi/BT and the DSI header. I'd take a B++ any day of the week for what I need, though I suppose the Zero in its current configuration would mostly meet my criteria, though I'd really like to get away from the WaveShare displays and into the official Raspberry Pi Foundation touchscreen. Boggles my mind that the Zero was released without a DSI header to be compatible with the display.

Return to “Advanced users”