0

I am overclocking my raspberry pi. I have selected the turbo option from the raspi-config. I have found out however that the Pi was not running consistently at 1GHz. I have tried setting the governor (in root using echo ...) to "performance" however it reverts to the default "on demand" after reboot. I need the pi to run consistently at 1 GHz so I decided to select the force_turbo=1 at config.txt. However, it does not run consistently at the set arm frequency but runs at the default 700MHz even at 45% cpu load while running my code. I have check the temperature, cpu load, and arm_freq using vcgencmd (get_config, measure_temp, measure_clock) command.

Isn't the force turbo option suppose to disable dynamically changing clock frequencies and set the arm frequency set at config.txt consistently even at low load?

Here's my config.txt:

gpu_mem=64
start_x=1
dtparam=spi=on
dtparam=i2c1=on
dtparam=i2c1_baudrate=400000
dtparam=i2c_arm=on
dtparam=i2c_arm_baudrate=400000
force_turbo=1
arm_freq=1000
core_freq=500
sdram_freq=600
over_voltage=6

Here's my rc.local:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

sudo echo performance > sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

exit 0

EDIT:

I have found the culprit. It was an undervoltage problem due to what supply I used. The problem was solved by using a separate supply. An indicator of an undervoltage problem is the appeareance of a multicolored square at the upper right corner of the desktop as well as the simultaneous flickering/blinking of the red power led of the pi. Undervoltage automatically disables force turbo to protect from sd card corruption.

1
  • 1
    As per my answer do not use sudo in /etc/rc.local. It is pointless since the script is run root by init, won't work with redirection (>) under any circumstances, and may cause that to fail if there is no path (the shell has an echo built-in, so that is okay). Also (this has nothing to do with your problem), start_x=1 enables the camera but you probably won't be able to use it unless gpu_mem is >= 128.
    – goldilocks
    Aug 11, 2016 at 11:16

1 Answer 1

1

Isn't the force turbo option suppose to disable dynamically changing clock frequencies and set the arm frequency set at config.txt consistently even at low load?

According to the documentation, yes. I don't have an explanation for why it would not.

I have tried setting the governor (in root using echo ...) to "performance" however it reverts to the default "on demand" after reboot.

Because the "files" in /sys (and /proc, and /dev) exist only conceptually -- they are kernel interfaces, not bytes stored on the SD card. Nothing set there persists across boot.

If you wish to set the governor at boot, on Raspbian you can do so via /etc/rc.local. You should not use sudo sh there, just echo performance > ....

8
  • will changing the governor to performance help with the force_turbo as the latter alone does not set my pi to run at 1GHz ? Aug 11, 2016 at 5:52
  • i tried setting the governor to perfomance to be persistent at every boot via etc/rc.local Aug 11, 2016 at 7:30
  • You've never explicitly mentioned setting arm_freq or asked how to overclock it so I presume you have done this? I.e., you have arm_freq=1000 in /boot/config.txt? Have you check through the file to make sure it is not overridden by a later entry? I don't use force_turbo or the performance governor (as implied before, I think it is pointless to do so), but I use arm_freq=900 and that works; when the processor is under load it jumps from 600 to 900.
    – goldilocks
    Aug 11, 2016 at 10:57
  • 1
    I've linked this already but maybe you want to take a closer look (also, there are other links in there): github.com/raspberrypi/documentation/blob/master/configuration/…
    – goldilocks
    Aug 11, 2016 at 10:57
  • 1
    You could try lower values to check if they work (although it if isn't going to work, I think it would shut down, etc). You can busy loop a processor core in one terminal with while true; do : ; done (to stop, use ctrl-c) and in another while that is still going check the cpu frequency with vcgencmd measure_clock arm; it should be the maximum.
    – goldilocks
    Aug 11, 2016 at 11:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.