Orange Pi Plus2E changing CPU speed?

[sheffield_nick]

Firstly many thanks to all the hard work from the Armbian developers - it installed onto the eMMC of my new Orange Pi Plus2E first time with no problems

 

I'm trying to benchmark the board (with a fan/heatsink) and without. The standard Armbian runs it at a maximum of 1.296GHz but I'd like to run it faster. I'm new to using fex, but this appears to push it up to 1.536GHz with a Vdd of 1.5V:

cd
bin2fex /boot/bin/orangepiplus2e.bin orangepiplus2e.heatsink.fex
sed -i "s/1296000/1536000/g; s/1320/1500/" orangepiplus2e.heatsink.fex
cp /etc/default/cpufrequtils /etc/default/cpufrequtils~
sed -i "s/1296000/1536000/" /etc/default/cpufrequtils
fex2bin orangepiplus2e.heatsink.fex /boot/bin/orangepiplus2e.heatsink.bin
mv /boot/script.bin /boot/script.bin~
ln -s /boot/bin/orangepiplus2e.heatsink.bin /boot/script.bin
reboot

have I missed anything? Is it possible to run it at the 1.6GHz that the board is advertised at?

 

Many thanks

[wildcat_paris]

please, H3 SoC is under development on Armbian, be careful with overclocking.

 

OPI+2E is quite a nice board, don't burn it.

[Ford Prefect]

The frequency must be a multiple of 24 so don't try 1600 MHz

I found a scrip called : fix-thermal -problems.sh

It is a good starting point.

It was designed to help with other distributions but works here too.

I believe that big variations of board temperature are bad for reliability so

I limited my ambitions until I find a useful application that really needs it

My board never exceeded 60 degrees with a big CPU radiator.

[zador.blood.stained]

have I missed anything? Is it possible to run it at the 1.6GHz that the board is advertised at?

It should be possible, even though I wouldn't recommend doing it without active cooling. In this case you probably didn't edit MAX_SPEED in /etc/default/cpufrequtils

 

I found a scrip called : fix-thermal -problems.sh

It is a good starting point.

It was designed to help with other distributions but works here too.

This was designed for other distributions, I would not run this on Armbian since we should have better default settings.

[sheffield_nick]

It should be possible, even though I wouldn't recommend doing it without active cooling. In this case you probably didn't edit MAX_SPEED in /etc/default/cpufrequtils

 

Thanks, I had, but managed to miss it out in my post... (now edited to include it).

[zador.blood.stained]

Did you check dmesg for any error messages and cpufreq-info for list of available frequencies?

[tkaiser]

I'm trying to benchmark the board (with a fan/heatsink) and without. The standard Armbian runs it at a maximum of 1.296GHz but I'd like to run it faster. I'm new to using fex, but this appears to push it up to 1.536GHz

 

Where's the point? Is there a single benchmark available that does not scale linearly with CPU clockspeed? So if you know how fast your device is when running at 1296 MHz you can take the most primitive calculator you want to get the idea how fast it will be when running at 1536 MHz?

 

The more interesting question is: Do you want an annoying fan or not? If not then the key to more performance are sane dvfs settings (with your 1.5V approach you're far away from sane settings, it's just a huge step back into loboris times). So if you want to do number crunching on a cheap H3 then use a fan and whatever settings you want (and maybe realize that a H3 is the wrong device for number crunching anyway), if not then enjoy Armbian's dvfs/THS settings and silence.

 

To get the idea how to develop sane dvfs/THS settings this here might help probably: http://forum.armbian.com/index.php/topic/1493-add-armbian-test-reliability-package-to-our-repo/

 

@Ford Prefect: Zador's right. My fix-thermal-problems.sh script was written before we finetuned the settings in Armbian. So while this might cure insane thermal settings in older OS images for H3 boards staying with Armbian defaults is strongly recommended. 

[sheffield_nick]

I don't like fans either, especially the noisy ones  and I really appreciate the work you've done to get some sensible, energy-efficient settings with Armbian. But I was still curious about whether the boards would really run at their advertised max speed, and how much cooling that would require.

[tkaiser]

In the aforementioned thread there is a link to a specific Linpack version from ssvb and also some insights into the relationship between clockspeed and temperature.

 

I did some tests back in March with H3 as well and with really heavy workloads (eg. cpuminer) I found that further increasing clockspeed above 1344 would require way better cooling (experimented with different sorts of 'heatpipe' to use large and slow rotating fans concentrating the airflow above the heatsink's surface). 1536 MHz compared with 1344 or 1296 is 15%-20% more performance at an enourmos 'cost' due to increased VDD_CPUX (performance per watt). And since H3 is the wrong device for number crunching anyway it simply doesn't matter. Or in other words: Frying your board at 1.5 GHz is laughable.

 

The "1.6 GHz" was something Xunlong wrote in the beginning when starting to sell OPi Plus. No one knows why. There are some comments in Allwinner's fex files that indicate while being able to reach these high clockspeeds those are only for benchmarking (fooling customers producing high Antutu scores). So why should we care about these '1.6 GHz' at all?

 

After wasting several days of testing we now know that H3 on the larger Oranges can reliably run at 1.3 GHz without the need for a fan or a special PSU and so on. Exceeding this requires a huge amount of efforts if you're also concerned about reliability. If it's just the usual moronic overclocker attempt ('hey, my board idles at 2.0 GHz and consumes 6W doing nothing!' -- psst don't tell anyone that it crashes when I put just some load on it) then do whatever you want. But if you want to check out RELIABLE operation at higher clockspeeds then be prepared that you've waste some time.

 

BTW: If you come up with Linpack settings that run at least 10 minutes on H3 it would be great since we could use them for undervoltage testing -- see the link to the other forum thread above. I experimented with Linpack already but the execution is way too short and therefore H3 doesn't heat up to the max. And my first attempt testing undervolting using cpuburn-a7 prior to Linpack (just to heat the SoC) always led to freezes/crashes which is bad since AFAIK we have no working watchdog driver with H3/legacy to recover from such situations. The nice thing with Linpack is that it already detects undervoltage related data corruption while the OS is still stable.

[Andrew DD]

I don't know why tkaiser is acting like a OVERCLOCK POLICE in the related posts and it starts to look a bit unnecessary  annoyance. Yeah yeah we all know 1.5v and 1.6GHz is not a good idea but that is not the point. We want to do what we can(want to) do even if it is a stupid idea. Isn't it the point of whole open source world? Why not just use a Windows? They are obviously much more controlled than Linux. If he prefers CONTROL so much over FREEDOM.

 Rather than explaining why overclocking is stupid, I would much appreciate to see some answers that OP is looking for.

[jernej]

Why don't you look at original Loboris settings then? Nobody here is comfortable to give you instructions how to shorten your board life. After all, a lot of time was spent to convince everyone that 1.6 GHz @ 1.5V hurts the chip.

[rodolfo]

We want to do what we can(want to) do even if it is a stupid idea. Isn't it the point of whole open source world?

 

Open source was a marketing gag by IBM trying to usurp the professional work of the free software world. The Armbian team does a stellar professional job to convert some random heaps of assorted hardware into useful working systems. There is a lot of dedication, pride and hard work to put some basic sanity into this tinker world.

 

True FREEDOM in software is complete CONTROL.   Don't blame professionals for doing their job. Feel free to run your car off the cliff.

[zador.blood.stained]

I don't know why tkaiser is acting like a OVERCLOCK POLICE in the related posts and it starts to look a bit unnecessary  annoyance. Yeah yeah we all know 1.5v and 1.6GHz is not a good idea but that is not the point. We want to do what we can(want to) do even if it is a stupid idea. Isn't it the point of whole open source world? Why not just use a Windows? They are obviously much more controlled than Linux. If he prefers CONTROL so much over FREEDOM.

 Rather than explaining why overclocking is stupid, I would much appreciate to see some answers that OP is looking for.

Overclocking H3 based boards is an option for users who believe in rationalism and not for users who believe in marketing bullshit. So @tkaiser simply protects this forum from users that would set their boards to 1.6GHz instead of 1.2GHz just because 1.6 is higher than 1.2, and then whine that "my board doesn't work anymore", "armbian is unstable" and "armbian sucks".

[shahidali55]

Also, there seems to be a thick copper layer in the multi-layer PCB of the Orange Pi One and Orange Pi PC. This helps take away some of the heat from the SoC but also ends up heating rest of the stuff on the board, including the micro SD card. Not sure how a long a micro SD card would last at a constant 65/70 deg C

 

Armbian is rock solid !!! If anyone wants a custom flavor of the OS, the build system also works perfectly !

[tkaiser]

Also, there seems to be a thick copper layer in the multi-layer PCB of the Orange Pi One and Orange Pi PC.

 

This is true for all Orange Pi variants I tested personally (only the interesting ones without internal USB hub, so no idea whether this applies to OPi 2, Plus or Plus 2, but all the others have copper layers in the PCB). If something's as hot as 65°C/70°C then it will hurt if you put a finger on it. Just let cpuburn-a7 run on an Orange Pi One (where SD card and SoC are pretty close) and try it out after 5 minutes yourself. SD card slot feels warm but can be touched without harming yourself.

 

BTW: There exist not many reasons to buy crappy SD cards since fast and reliable quality SD cards don't cost much more (if at all). The recommended Samsung EVO TF cards for example are rated for an operational temperature range of -25°C to +85°C, the ICs used on these cheap boards should be in conformance with commercial temperature range (up to 70°C) so why should we care at all?

 

Armbian uses some safety headroom with thermal/throttling settings for H3 boards, even if thermal trip points would be increased to the max (not already at 75°C SoC temperature starting to throttle but getting closer to H3's maximum operation temperature of 125°C!) I still don't see a problem with spreading the heat accross the PCB. If you ever pulled a PCB out of a small enclosure it feels way more hot compared to any Orange being under load.

[iresearch3]

i buyed an orange pi h3 to play.

 

only for information and thanks to sheffield_nick

 

the orange is running at 1536 for two weeks at 1.5v without isues, some hard tests made during it.

 

passive cooler on it max temp reached 73º.

 

i tryed to up to 1.608.000 hz but the freq dont up.

 

reliable go more 

 

power source is 2.1a  max

 

sorry for my english

[tkaiser]

i tryed to up to 1.608.000 hz but the freq dont up.

 

reliable go more

 

LOL! Please use cpuburn-a53, let it run for 10 minutes and then show me the output from 'sudo armbianmonitor -m' running for at least 30 seconds.

 

BTW: The cpufreq steps above the recommended/reliable 1.3 GHz are as follows: https://github.com/igorpecovnik/lib/blob/master/patch/kernel/sun8i-default/cpufreq-add-more-frequencies.patch#L53-L55

[iresearch3]

hi i tested and with some consoles open. i post the armbianmonitor out.

why the temp up and down?

 

with sysbench some degrees less. peak reached 78 degrees

 

test sysbench, cpuburn, and the cpuburn+sysbench in two consoles.

 

the machine still without rebooting

 

results with cpuburn (with sysbench+cpuburn the clock and temp dont go down never) 50min running armbianmonitor -m

 

20:27:09: 1536MHz  5.97  68%  15%  52%   0%   0%   0%   72°C
20:27:15: 1536MHz  6.66  68%  15%  52%   0%   0%   0%   72°C
20:27:20: 1536MHz  6.93  68%  15%  52%   0%   0%   0%   72°C
20:27:25: 1536MHz  7.18  68%  15%  52%   0%   0%   0%   73°C
20:27:30: 1536MHz  7.40  68%  15%  52%   0%   0%   0%   72°C
20:27:36: 1536MHz  7.61  68%  15%  52%   0%   0%   0%   72°C
20:27:41: 1536MHz  7.80  69%  15%  52%   0%   0%   0%   72°C
20:27:46: 1536MHz  7.98  69%  15%  52%   0%   0%   0%   72°C
20:27:52: 1536MHz  8.14  69%  15%  52%   0%   0%   0%   73°C
20:27:57: 1536MHz  8.29  69%  15%  53%   0%   0%   0%   72°C
20:28:02: 1536MHz  8.43  69%  15%  53%   0%   0%   0%   74°C
20:28:07: 1536MHz  8.55  69%  15%  53%   0%   0%   0%   73°C
20:28:13: 1536MHz  8.75  69%  15%  53%   0%   0%   0%   72°C
20:28:18: 1536MHz  8.85  69%  15%  53%   0%   0%   0%   72°C
20:28:23: 1536MHz  8.94  69%  15%  53%   0%   0%   0%   72°C
20:28:29: 1536MHz  9.03  69%  15%  53%   0%   0%   0%   74°C
20:28:34: 1536MHz  9.10  69%  15%  53%   0%   0%   0%   73°C
20:28:40: 1536MHz  9.26  69%  15%  53%   0%   0%   0%   72°C
20:28:45: 1536MHz  9.37  69%  15%  53%   0%   0%   0%   72°C
20:28:50: 1536MHz  9.42  69%  15%  53%   0%   0%   0%   72°C
20:28:56: 1536MHz  9.47  69%  15%  53%   0%   0%   0%   74°C
20:29:01: 1536MHz  9.51  69%  15%  53%   0%   0%   0%   73°C
20:29:06: 1536MHz  9.55  69%  15%  53%   0%   0%   0%   73°C
20:29:12: 1536MHz  9.58  69%  15%  54%   0%   0%   0%   73°C
20:29:17: 1536MHz  9.62  69%  15%  54%   0%   0%   0%   72°C
20:29:23: 1536MHz  9.65  69%  15%  54%   0%   0%   0%   72°C
20:29:28: 1536MHz  9.68  69%  15%  54%   0%   0%   0%   73°C
20:29:33: 1536MHz  9.70  70%  14%  54%   0%   0%   0%   73°C
20:29:39: 1536MHz  9.73  70%  14%  54%   0%   0%   0%   73°C
20:29:44: 1536MHz  9.75  70%  14%  54%   0%   0%   0%   74°C
20:29:49: 1536MHz  9.77  70%  14%  54%   0%   0%   0%   72°C
20:29:55: 1536MHz  9.79  70%  14%  54%   0%   0%   0%   74°C
20:30:00: 1536MHz  9.89  70%  14%  54%   0%   0%   0%   75°C
20:30:05: 1536MHz  9.90  70%  14%  54%   0%   0%   0%   74°C
20:30:11: 1536MHz  9.91  70%  14%  54%   0%   0%   0%   73°C
20:30:16: 1536MHz  9.92  70%  14%  54%   0%   0%   0%   73°C
20:30:21: 1536MHz  9.92  70%  14%  54%   0%   0%   0%   73°C
20:30:27: 1536MHz  9.93  70%  14%  54%   0%   0%   0%   65°C
20:30:32: 1536MHz  9.94  70%  14%  55%   0%   0%   0%   70°C
20:30:37: 1536MHz  9.94  70%  14%  55%   0%   0%   0%   74°C
20:30:43: 1536MHz  9.95  70%  14%  55%   0%   0%   0%   72°C
20:30:48: 1536MHz  9.95  70%  14%  55%   0%   0%   0%   70°C
20:30:53: 1536MHz  9.95  70%  14%  55%   0%   0%   0%   66°C
20:30:59: 1536MHz  9.96  70%  14%  55%   0%   0%   0%   73°C
20:31:04: 1536MHz  9.96  70%  14%  55%   0%   0%   0%   74°C
20:31:26: 1536MHz 10.04  71%  14%  55%   0%   0%   0%   72°C
20:31:31: 1536MHz 10.03  71%  14%  55%   0%   0%   0%   75°C

[iresearch3]

Ways to jump this limit?

another kernel?

[Igor]

Ways to jump this limit?

another kernel?

Read two posts up.

[James Kingdon]

Hi,

 

I have a slightly unusual use case, building a compile and test farm with a variety of different socs so that I can easily check for regressions. All the boards will have heatsinks and active cooling so I have more thermal budget than may be typical, and I'd like to run at the higher clockspeeds to push the tests through more quickly.

 

I've just added an Orange pi pc+ and installed Armbian_5.25_Orangepipcplus_Ubuntu_xenial_default_3.4.113 onto the emmc (which went very smoothly - many thanks as always for the great work you do).

 

cpufreq-info shows steps upto 1.54 GHz, but hardware limits between 480 MHz and 1.30 GHz.

analyzing CPU 0:
  driver: cpufreq-sunxi
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 2.00 ms.
  hardware limits: 480 MHz - 1.30 GHz
  available frequency steps: 60.0 MHz, 120 MHz, 240 MHz, 312 MHz, 408 MHz, 480 MHz, 504 MHz, 528 MHz, 576 MHz, 600 MHz, 624 MHz, 648 MHz, 672 MHz, 720 MHz, 768 MHz, 816 MHz, 864 MHz, 912 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.44 GHz, 1.54 GHz
  available cpufreq governors: interactive, conservative, ondemand, powersave, userspace, performance
  current policy: frequency should be within 624 MHz and 1.30 GHz.
                  The governor "interactive" may decide which speed to use
                  within this range.
  current CPU frequency is 624 MHz.
  cpufreq stats: 60.0 MHz:0.00%, 120 MHz:0.00%, 240 MHz:0.00%, 312 MHz:0.00%, 408 MHz:0.00%, 480 MHz:0.00%, 504 MHz:0.00%, 528 MHz:0.00%, 576 MHz:0.00%, 600 MHz:0.00%, 624 MHz:50.79%, 648 MHz:0.00%, 672 MHz:0.04%, 720 MHz:0.00%, 768 MHz:0.00%, 816 MHz:0.00%, 864 MHz:0.00%, 912 MHz:0.00%, 960 MHz:0.00%, 1.01 GHz:44.60%, 1.06 GHz:0.21%, 1.10 GHz:0.21%, 1.15 GHz:1.77%, 1.20 GHz:0.42%, 1.25 GHz:0.38%, 1.30 GHz:1.58%, 1.34 GHz:0.00%, 1.44 GHz:0.00%, 1.54 GHz:0.00%  (49)

During runs the maximum freq used is 1.30 GHz. I tried editing /etc/default/cpufrequtils and increasing the MAX_SPEED value, but it does not appear to have had any affect even after reboot.

 

How do I enable the higher frequency steps?

 

Regards,

James

[tkaiser]

23 minutes ago, James Kingdon said:

How do I enable the higher frequency steps?

 

What about reading the thread you're posting to?

 

It's explained in the first post above. You need to overvolt the SoC which will impact longevity (since you're violating chip specifications) and without active cooling you will most likely end up with lower performance anyway

 

The cpufreq operating points above 1.3 GHz are Allwinner's 'gift' for clueless Android customers and TV box vendors since the latter can claim "H3 running at 1.5 GHz" and the former believe this blindly since Android tools like CPU-Z and stupid benchmarks like geekbench will both show 1536GHz as maximum cpufreq (while you would need to adjust in fex file both dvfs operating points and appropriate values in cooler table to exceed the lower default values)

[James Kingdon]

Thanks for the reply. Sorry if I didn't make my question clear enough, I read the thread and attempted to follow what I could see but was unsuccessful. Hence the question asking for further guidance. And yes, I plan on using active cooling and monitoring temperatures during runs. At the moment my particular workloads only raise the cpu temp to about 45C and I'm comfortable with running the board hotter than that.

 

I checked that /boot/script.bin was linked to bin/orangepipcplus.bin and ran bin2fex on it, but the dvfs_table in there doesn't seem to match the frequencies listed by cpufreq-info, so I'm a bit confused as to how this works. It looks like the fex is being modified or over-ridden by the patch you referenced a few posts up. How does that work?

[zador.blood.stained]

As far as I understand:

• "available frequency steps" are hardcoded in the cpufreq driver and can be changed with recompilation
• "hardware limits" are defined in the FEX file, most likely in dvfs section
• "current policy" comes from settings in /etc/default/cpufrequtils

I'm not goint to test if everything above is correct. Feel free to experiment, and if you have any questions - kernel sources are available for you to study. Most people here are happy with the provided defaults and won't spend their time on worthless experiments.

[tkaiser]

26 minutes ago, James Kingdon said:

the dvfs_table in there doesn't seem to match the frequencies listed by cpufreq-info

 

Yes, those are two different things: cpufrequtils/cpufreq-info does the same as CPU-Z on Android or Geekbench: listing numbers without meaning (and that's by intention, all those Android SoC vendors 'tune' their kernels in the same way). What's possible in reality @zador.blood.staineddesribed correctly.

 

And please don't be confused: I usually answer posts with others reading threads later in mind (that's why I insinst over and over again that it's rather useless to adjust Armbian's dvfs settings since we wasted days to optimize them  )

[James Kingdon]

Many thanks for the additional info, that was enough to get me in the right place. With 1.54GHz enabled my workload runs in the low fifties centigrade without the fan fitted. I'd expect to take another 5 to 10C off that when the fan is in place. So far no signs of instability but if I run into any problems I'll back the changes off.

 

I'd have to rate the board as very impressive for thermal management, certainly compared to the odroid XU4 which pays for the speed with a whole lot of heat.

[infeeeee]

Hello 

I'm not sure if it's belong here, but I didn't find any closer thread.

I'm trying to overclock my orange pi zero 256MB,  armbian 5.24 stable. 

I edited the fex file like in the first post, not with sed but with nano(is it a problem?).

I change the dvfs frequency in the fex file, and the max value in /etc/default/cpufrequtils to the same value.

Here is my dvfs table from fex file, I only modified only the max_freq and LV1freq:

[dvfs_table]
pmuic_type = 1
pmu_gpio0 = port:PL06<1><1><2><1>
pmu_level0 = 11300
pmu_level1 = 1100
max_freq = 1344000000
min_freq = 240000000
LV_count = 6
LV1_freq = 1344000000
LV1_volt = 1300
LV2_freq = 1008000000
LV2_volt = 1300
LV3_freq = 912000000
LV3_volt = 1100
LV4_freq = 648000000
LV4_volt = 1100
LV5_freq = 480000000
LV5_volt = 1100
LV6_freq = 240000000
LV6_volt = 1100

 

If I change the voltage to more than 1.3v the max frequency doesn't go up on load to the lv1 freq, it remains at 1.008GHz as the lv2_freq.

This is maybe because according to the linux-sunxi page on opi zero the max voltage is 1.3v??

 

If I don't change the lv1 voltage, but the lv1 freq, the cpu goes up to 1.2GHz only, not the frequency I set in fex and in cpufrequtils.

My guess is that I have to change the frquency somewhere else as well? I've read the this forum and I don't have a clue what I'm missing.

Thanks for your help!

 

[tkaiser]

10 minutes ago, infeeeee said:

I'm trying to overclock my orange pi zero 256MB

 

Forget it. Unless you're very good in soldering you can only switch between 1.1V and 1.3V (there's only one GPIO switch adjusting voltage) and with 1.3V you can't exceed 1200 MHz without risking instabilities. With 64-bit ARM boards this here would help you to check the limits (let xhpl64 fail and reduce the clockspeed further) but it's absolutely useless to try this with H2+ boards.