Manual dynamic overclocking


13 posts
by Tieum » Wed Oct 24, 2012 9:08 am
Hello,

I have read a lot about dynamic overclocking and most if not all answers to what should I do are: raspi-config

Well raspi-config is not avaialble on fedora but I still would like to try manual overclocking. I added the belowlines to my config.txt to try and get the "Modest" mode from raspi-config. My issue is that the overclocking does not look much dynamic as CPU freq is stuck at 800 even when the CPU load is very low. How can I get real dynamic overclocking on my fedora disto?

force_turbo=0
arm_freq=800
core_freq=300
sdram_freq=400
over_voltage=0

Thanks.
Posts: 11
Joined: Wed Sep 26, 2012 8:46 am
by Tieum » Thu Oct 25, 2012 11:10 am
So I put Raspian on an SD card to find out what is in the config.txt file. It is the same as I have.

What am I missing in Fedora to get dynamic overclocking? Is there a kernel option to activate?

Thanks in advance.
Posts: 11
Joined: Wed Sep 26, 2012 8:46 am
by zerophnx » Thu Oct 25, 2012 4:53 pm
I was curious about this too, since I might use an extra SD card for another distro.

I took a look at what the raspi-config actually changes. You can find it at: https://github.com/asb/raspi-config/blob/master/raspi-config

The overclock section starts at line 178.

If I'm understanding this correctly, raspi-config is writing the values to config.txt and enabling the ondemand cpu governor on boot (AFAIK this is what makes it dynamic).

I think you could do this manually by editing the config.txt and running:
Code: Select all
echo "ondemand" > $SYS_CPUFREQ_GOVERNOR
at startup.

If possible, you should copy the whole initscript in the source to enable the shift protection instead of just running this line every time. You never know.

Again, this is just my guess. If somebody else knows more, please fill us in!
User avatar
Posts: 16
Joined: Wed Aug 15, 2012 5:43 pm
Location: NY, USA
by zerophnx » Thu Oct 25, 2012 8:24 pm
Forgot: I think any approach that changes the CPU governor to ondemand will work, it might not have to be the way he did it.

Take a look at the source link to see what I mean.
User avatar
Posts: 16
Joined: Wed Aug 15, 2012 5:43 pm
Location: NY, USA
by Tieum » Fri Oct 26, 2012 8:17 am
Thanks for the hint.

I added the following line to /etc/rc.d/rc.local and it works fine now

Code: Select all
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Posts: 11
Joined: Wed Sep 26, 2012 8:46 am
by Synthetic_Darkness » Mon Oct 29, 2012 5:53 am
Mind the question. But does that mean you have enabled dynamic overclocking yourself ie: not using Raspbian?

That's very very cool.
http://codefridge.com/ - where cool code comes to chill.
Posts: 30
Joined: Sun Sep 23, 2012 12:22 pm
Location: JHB, South Africa
by zerophnx » Thu Nov 01, 2012 5:21 pm
We're doing it the same way it's done in Raspbian. Since Tieum says it's working for him (I haven't tried it yet), it should work in any OS that includes the ondemand governor, which I believe comes as a kernel module and is in almost every distro.

Time permitting I wanted to try another OS (a minimalist/specialty one called TinyCore) on the Pi soon and the dynamic overclocking would be wonderful for that, especially if I'm doing compiling!

Edit: Spelling/grammar
User avatar
Posts: 16
Joined: Wed Aug 15, 2012 5:43 pm
Location: NY, USA
by Tieum » Sun Nov 04, 2012 10:12 am
What puzzles me in this is what the turbo_mode setting in config.txt is for.

By default on Fedora overclocking is always active which is equivalent to setting turbo_mode=1 if I understand correctly.

What is turbo_mode really doing?
Isn't setting cpu_freq to performance a way to bypass turbo_mode and avoid having the warranty bit set?
Posts: 11
Joined: Wed Sep 26, 2012 8:46 am
by zerophnx » Mon Nov 05, 2012 2:51 pm
Config options are explained pretty well on eLinux. Overclocking in general (with ideas how to not void the warranty) is explained here:
http://elinux.org/RPi_config.txt#Overclocking

The force_turbo option specifically is referenced a little below there.
User avatar
Posts: 16
Joined: Wed Aug 15, 2012 5:43 pm
Location: NY, USA
by Tieum » Tue Nov 06, 2012 4:45 pm
Sorry but I am as confused as before.

"force_turbo=1disables dynamic clocking, so all frequencies and voltages stay high"

How is this different from setting cpu_freq to performance?
Posts: 11
Joined: Wed Sep 26, 2012 8:46 am
by zerophnx » Wed Nov 07, 2012 6:01 pm
Oops! Forgot to post my comment before closing the window yesterday.

I think they do the same thing but in different ways.

As far as I know, CPU governors are pieces of software (kernel modules) telling the hardware what it wants it to do (in performance's case, run at full speed all the time).

In contrast, the "force_turbo" option may be the GPU forcing the ARM to do the same thing without any software governor.

Unless you need the system to be at full speed all the time, you're probably better off with ondemand, which will save some power when the system isn't under load (I don't know the load needed to make the cpu speed up).
User avatar
Posts: 16
Joined: Wed Aug 15, 2012 5:43 pm
Location: NY, USA
by Tieum » Fri Nov 09, 2012 2:49 pm
I am under the same impression that they do the same thing.

How does setting cpu_freq to performance or not affect the warranty bit?
Posts: 11
Joined: Wed Sep 26, 2012 8:46 am
by zerophnx » Thu Nov 15, 2012 4:50 pm
I'm pretty sure the warranty bit is only affected by using certain config.txt settings.

The CPU governor on its own doesn't really effect anything without those settings being adjusted.

The worst thing any governor could do with a "stock" config.txt is run the Pi at 700mhz all the time, which would already happen without it being there.
User avatar
Posts: 16
Joined: Wed Aug 15, 2012 5:43 pm
Location: NY, USA