User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

arm_freq non changing?

Sun Oct 09, 2016 3:51 am

On my RPi 3 with the Pixel Desktop firmware, and running Raspbian Jessie no matter what settings I put into the Config.txt it reports running at 1000MHz. This is with force_turbo obviously.

Is this an error on what Raspbian is reporting or an error in the firmware?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: arm_freq non changing?

Sun Oct 09, 2016 4:01 am

Ok sorry.

Though for the reference of anyone else that finds this problem:
There is an entry in the config.txt file about two thirds of the way down that sets arm_freq=1000, so anything you set will be overridden by that if you do not notice it and comment it out.

Now i am running at 1200MHz again :), and keeping an eye on the temperature (as normal):

Code: Select all

avoid_warnings=2
force_turbo=1
arm_freq=1200
arm_freq_min=900
core_freq=500
sdram_freq=500
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Graymalk
Posts: 55
Joined: Wed Nov 11, 2015 8:33 pm

Re: arm_freq non changing?

Sun Oct 09, 2016 11:17 pm

I saw that on my first Pi 3. I found it confusing because I expected 1200 and kept seeing references here to 900.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: arm_freq non changing?

Mon Oct 10, 2016 3:26 am

Well everything is working well here now. I am currently ruining at 1.35GHz and stable all day long.

Though also note that there is a over_voltage setting near the end of the config.txt that will override any earlier setting.

Though I am running with the overclock settings:

Code: Select all

avoid_warnings=2
force_turbo=1
arm_freq=1350
arm_freq_min=900
core_freq=500
sdram_freq=500
over_voltage=6
temp_limit=80
boot_delay=2
And on my RPi 3B it is stable, may not be on others.

Next thing will be to try a slightly higher freq for the SDRAM, then maybe a slight bump on the core_freq, if all goes well that far it will be time to give 1.4GHz a try on the ARM.

Obviously the over clocking is not recommended, and can cause significant trouble. The reports I have read say that some RPi 3B's can take a bit more than others, which makes since.

My first RPi B (from 2012) could not be clocked past 900MHz stable no matter what I did, my second RPi B (2012 as well) could take 1150MHz with no trouble at all, and my current RPi 1B can take 1200MHz stable, so I would expect there to be at least as much of a variable with the RPi 3B.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: arm_freq non changing?

Mon Oct 10, 2016 4:17 am

This thread got me thinking back to when I was using a RPi B (model 1B) as my main desktop computer. So I unhooked my RPi B from the home made IO expander and driver board of my 3D printer, chaqnged the clock settings on the config.txt of the Raspbian SD I am using on the RPi 3B (pixel desktop), and switched RPi's.

I can say that the Pixel Desktop version of Raspbian is way way slower than the old Raspbian distro (that I still have on an SD Card (full size so only for the old RPi's)).

I am sure the slow down is only with the Window manager and some of the X applications. Though I always thought that part of updating software was improving the performance, so it will run faster with less memory usage on the same exact hardware while improving the functionality, obviously the maintainers of Raspbian do not share this view.

I expected that Chromium would be quite a bit slower than Epipheny, though these are different programs, so not a big thing.

Now to see how the current RISC OS does on the Raspberry Pi B, ARMv6 single core system at 1200MHz CPU, 500MHz RAM, and 500MHz core.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4843
Joined: Wed Feb 04, 2015 6:38 pm

Re: arm_freq non changing?

Mon Oct 10, 2016 10:32 am

DavidS wrote:Well everything is working well here now. I am currently ruining at 1.35GHz and stable all day long.
That's a good overclock. None of mine will come near that, even with a heatsink.

I find the Pi might well boot and run OK, but later when you do a larger job (such as a large compilation) it will fail randomly for no obvious reason. Down-clocking will make the build run OK. So stress testing is needed.

Have you tried cpuburn?

Code: Select all

wget https://raw.githubusercontent.com/ssvb/cpuburn-arm/master/cpuburn-a53.S
gcc -o cpuburn-a53 cpuburn-a53.S
./cpuburn-a53
Its a small assembler program that uses NEON on all 4 cores.
If it runs for a couple of hours or so with no problems (and everything else works properly), you are likely stable.

Monitor the temp with:

Code: Select all

vcgencmd measure_temp
and the frequency with

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
as it will probably throttle back.

You should also run one or more instances of memtester since your memory is a little overclocked:

Code: Select all

sudo apt install memtester

Code: Select all

sudo memtester 600m 10
or more if running headless.

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

Re: arm_freq non changing?

Mon Oct 10, 2016 11:09 am

jahboater wrote:and the frequency with

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
as it will probably throttle back.
That won't tell you what frequency it's running at, "scaling_cur_freq" contains the upper limit value for turbo. It won't change once the Pi has booted and will always contain the default of 1200, or whatever overclock/underclock value you've set in config.txt.

To check what frequency it's currently running at use "vcgencmd measure_clock arm", or look in "cpuinfo_cur_freq" using something like

Code: Select all

sudo watch -n 1  cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
which will provide 1 second updates showing the current speed (lists all four cores).

jahboater
Posts: 4843
Joined: Wed Feb 04, 2015 6:38 pm

Re: arm_freq non changing?

Mon Oct 10, 2016 11:22 am

JimmyN wrote:
jahboater wrote:and the frequency with

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
as it will probably throttle back.
That won't tell you what frequency it's running at, "scaling_cur_freq" contains the upper limit value for turbo. It won't change once the Pi has booted and will always contain the default of 1200, or whatever overclock/underclock value you've set in config.txt.
????
This shows the upper limit value for turbo:

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
this shows the lower limit:

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
and shows the current value:

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
Assuming you are using the default ondemand governor it will show 600Mhz on an idle machine. See:

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
All four cores will be the same.
You want cpuburn to run unhindered, so run as little as possible at the same time, anything else running will reduce the load.

User avatar
jojopi
Posts: 3088
Joined: Tue Oct 11, 2011 8:38 pm

Re: arm_freq non changing?

Mon Oct 10, 2016 11:29 am

JimmyN wrote:That won't tell you what frequency it's running at, "scaling_cur_freq" contains the upper limit value for turbo. It won't change once the Pi has booted and will always contain the default of 1200, or whatever overclock/underclock value you've set in config.txt.
As the name suggests, scaling_cur_freq is the frequency currently requested by Linux' cpufreq governor. It is the speed the CPU should be running at, and it does indeed change.

scaling_cur_freq does not know about any over-temperature or under-voltage throttling imposed by the GPU firmware, however. For that you do need the more invasive queries.

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

Re: arm_freq non changing?

Mon Oct 10, 2016 11:35 am

Oooops, you're right, I was thinking about something else. You can get it with "scaling_cur_freq" or "cpuinfo_cur_freq".

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: arm_freq non changing?

Mon Oct 10, 2016 3:46 pm

Thank you for the input. I have ran a couple of multicore bench marks that I have laying around to stress test the CPU's, and all are stable. I have also ran a few different memory testers (bare metal, RISC OS based, and Linux based) to verify the memory is stable.

I have read that some RPi 3B's will not overclock very far.

I did find with mine that I had trouble at first, then I found the second over_voltage setting near the end of config.txt that was overriding my setting. Mine is stable with overvoltage of 4, though I wanted to be safe so I went with an over_voltage of 6.

I mostly use RISC OS which only uses one core, this probably helps as the other three cores surrounding that one core likely act as a heat sink, by distrubuting the heat over a greater area making it easier to carry away.

Currently the sensors read up to 72 degrees C, with a IR thermometer showing a max of 79 Degrees, probably where the one core is running. This is without any heatsink at all, running without a case and with the board oriented verticaly to allow better convection cooling.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4843
Joined: Wed Feb 04, 2015 6:38 pm

Re: arm_freq non changing?

Mon Oct 10, 2016 3:58 pm

DavidS wrote: I mostly use RISC OS which only uses one core, this probably helps as the other three cores surrounding that one core likely act as a heat sink, by distributing the heat over a greater area making it easier to carry away.
Yes - with one single core running you can over clock it a lot further. On the C2 you can fix the maximum number of cores to use, as you reduce the number, the documented safe over-clock increases.

As for over-voltage.
There is an upwards and downwards spiral.
As you increase the voltage, the temperature increases, which itself requires additional voltage for stability. You see the upwards spiral. The only solution is additional cooling.
As you decrease the voltage, it runs cooler, which needs less voltage for stability, so it runs even cooler. A happy downward spiral.
This is without any heatsink at all, running without a case and with the board oriented vertically to allow better convection cooling.
That's definitely the best position, and if you fit a heatsink make sure the fins are aligned vertically.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: arm_freq non changing?

Mon Oct 10, 2016 4:15 pm

:)


Is there a way to tell linux to boot single core? I do not do very much that takes any advantage from multicore, so it would be nice to be able to plop Raspbian to single core on the RPi 3B.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: arm_freq non changing?

Mon Oct 10, 2016 4:57 pm

I forgot to show two screen shots showing the running status at 1.35GHz.
Attachments
window0.gif
window0.gif (27.51 KiB) Viewed 2878 times
area0.gif
area0.gif (1.06 KiB) Viewed 2878 times
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4843
Joined: Wed Feb 04, 2015 6:38 pm

Re: arm_freq non changing?

Mon Oct 10, 2016 5:02 pm

DavidS wrote:Is there a way to tell linux to boot single core? I do not do very much that takes any advantage from multicore, so it would be nice to be able to plop Raspbian to single core on the RPi 3B.
You could try adding "maxcpus=1" to /boot/cmdline.txt
I have never tried it (happy with 4 cores) but it is supposed to work for Ubuntu (on the C2) and its just a kernel argument.

You may not use all the cores, but the system will. Systemd runs all the boot tasks in parallel as much as possible. Interrupts can be handled by a separate core from your task. Any other command you start will run in a different core. Make -j N will run multiple build tasks simultaneously, using all the cores. And so on. Having spare cores means commands you start should run instantly. A process hogging the cpu will not slow the system down, it will still be responsive.

Edit: just tried "maxcpus=1" for interest, and it works fine. Try htop which gives a bar graph type display of cpu usage (sudo apt install htop).
"systemd-analyze" shows the boot time increased from 7.7 seconds to 10.05 seconds on the single core.

jahboater
Posts: 4843
Joined: Wed Feb 04, 2015 6:38 pm

Re: arm_freq non changing?

Mon Oct 10, 2016 5:29 pm

And you will only get ONE raspberry on the console when you boot :o

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: arm_freq non changing?

Mon Oct 10, 2016 5:36 pm

jahboater wrote:And you will only get ONE raspberry on the console when you boot :o
LOL.

Yes build times may be improved by multicore, though I run those in the background at low priority anyway (would rather them take more time and use less processor time).

I know of the other advantages of MultiCore, and sometimes do take advantage of them in bare metal, though not in Linux (so it takes 11 seconds to boot, not a big deal it takes twice that to boot the Pixel Desktop on a RPi B).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4843
Joined: Wed Feb 04, 2015 6:38 pm

Re: arm_freq non changing?

Mon Oct 10, 2016 6:52 pm

Its a shame the hotplug governor isn't supported on raspbian
[email protected]:/sys/devices/system/cpu/cpu0/cpufreq $ cat scaling_available_governors
conservative ondemand userspace powersave performance
[email protected]:/sys/devices/system/cpu/cpu0/cpufreq $
The hotplug governor will completely de-activate unused cores.

I suppose another possibility would be to set arm_freq_min to something very low like 100Mhz.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: arm_freq non changing?

Mon Oct 10, 2016 10:38 pm

jahboater wrote:Its a shame the hotplug governor isn't supported on raspbian
[email protected]:/sys/devices/system/cpu/cpu0/cpufreq $ cat scaling_available_governors
conservative ondemand userspace powersave performance
[email protected]:/sys/devices/system/cpu/cpu0/cpufreq $
The hotplug governor will completely de-activate unused cores.

I suppose another possibility would be to set arm_freq_min to something very low like 100Mhz.
Does it make that huge of a difference?

If you have the unused cores executing WFI, and having no possible inturupt sources this should be almost as low power as turnning them off, correct?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4843
Joined: Wed Feb 04, 2015 6:38 pm

Re: arm_freq non changing?

Tue Oct 11, 2016 8:44 am

I don't know. Thinking about it, I don't think it does what you want anyway.

See this the table part way down this wiki (advanced frequency sets) for the C2 (its the same cortex-a53 cpu, but is 28nm):

http://odroid.com/dokuwiki/doku.php?id= ... t_cpu_freq

Perhaps a compromise would be set maxcpus=2, then you will still get an extra high overclock, but your core wont have to handle all the interrupts and other processes with the context switching overheads so much.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: arm_freq non changing?

Tue Oct 11, 2016 5:05 pm

'maxcpus=2' seems to work well.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Return to “General discussion”