1

As a follow-up to this question: Raspberry Pi B+ Overclocking: Force Turbo not working

I had trouble getting force turbo to work. I was using the command:

sudo vcgencmd measure_clock arm

to get the current frequency of the pi both in idle and when my PID code is running. The command returned a frequency measurement varying between 700MHZ and 1GHz which should not be the case as force_turbo disables dynamic clock frequency selection. Also to confirm this, my PID control loop rate also drops from 550Hz to 300Hz as the measured cpu frequency drops from 1GHz to 700MHz during test runs. This confirms that force_turbo is indeed not working.

However, I tried using different command:

sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

which I got from Arne's question: Why is my Pi running at 700MHz all the time?

I found that using this method of measurement consistently gave me an arm clock frequency of 1GHz which confirms that force_turbo is indeed working.

Also during booting, I found that written in the screen that the minimum arm frequency has been changed from 700MHz to 1GHz upon setting force_turbo=1. This was not the case when I set the governor to performance wherein the min arm frequency remained 700MHz.

However I am not sure which to trust. Does anyone know why these methods give out different readings?

Below is a screenshot of my tests with the two methods using two terminals:

  • Left terminal uses vcgencmd & Right terminal uses cat to check cpuinfo_cur_freq
  • Top terminal was used to execute scrot command for the screenshot
  • It is also worth noting that I used the ordinary terminal for vcgencmd and the root terminal for the cpuinfo command.

enter image description here

As a sidenote long ago, I had a similar experience where when I was running the code in the raspbian desktop interface vs the command line only interface, the code ran faster in the desktop interface which was interesting.

0

The vcgencmd command is the more accurate one as the vcgencmd command takes the reading from the firmware and the cpuinfo_cur_freq takes the reading from the kernel. The problem with using cpuinfo_cur_freq is that when the cpu throttles due to too low load, undervoltage, or high temperature, it does not get reported back to the kernel.

Source here and here

I hope this helps :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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