Operating the H3 in a reliable way (sane clockspeeds)

bronco

i just had a look into loboris' fex files for various H3 models just to realize that the following is defined:

1. boot_clock           = 1536
   
2. dram_clk        = 672
   
3. [dvfs_table]
   
4. max_freq = 1536000000
   
5. LV1_volt = 1500
   
6. LV2_freq = 1200000000
   
7. LV2_volt = 1300
   
8. [no more dvfs entries]

Copy code

In the very same fex files it's also written in comments how sane dvfs values should look like: http://linux-sunxi.org/Orange_Pi_PC#CPU_clock_speed_limit

Our friends at Olimex started yesterday to play with their first own H3 board and now it seems obvious where the heat problems of the H3 originate from: Insane high cpufreq/dvfs settings and maximum DRAM frequency. When adjusting that to sane values (DRAM 480 MHz, max_freq = 100800000 @ 1.2V) then the thermal problems went away: https://olimex.wordpress.com/201 ... test/#comment-20502

Anyone here that already did stability and data integrity tests? Following the guidelines outlined here: http://linux-sunxi.org/Hardware_Reliability_Tests#DRAM and https://groups.google.com/d/msg/ ... _Kl6n0/MnOCbvrgAgAJ

I read through the forums and people trying to get Mali and video acceleration to work every now and then complain about kernel oops they attribute to software stuff. But if hardware is operated beyond sane limits then this sort of problems is quite normal. So again: Did anyone already walk through the whole set of hardware reliability tests?

barquerito

You learn something new every day!

bronco

I did a set of tests without heatsink (on 2nd OPi PC). There it's even more obvious what's wrong with the overvolted settings:


An increase in idle temperature of 12°C when exceeding 1.2 GHz just due to the different voltage levels. Insane. Also interesting the results under full load: http://linux-sunxi.org/User_talk:Tkaiser#Tests_without_a_heatsink

With the insane default settings the H3 wastes more energy when running under full load at 480 MHz than compared to sane settings while at 1.2 GHz. Another plus: Thermal throttling works way better. It seems the Vcore voltage is also considered. In my settings I use 1.24V at 1200 MHz and was able to finish sysbench tests while exceeding 80°C -- with the overvolted default settings throttling would've occured way earlier and sysbench results are worse. Depending on the thermal conditions (small enclosure for example) the sane settings might even improve performance compared to the overvolted defaults since throttling would occur later or not at all.

The best news is: If there's appropriate airflow possible not even a heatsink is needed but the H3 can still run with 1.2 GHz under full load over longer periods of time. Time to stop here.

bronco

lymon replied at 2015-11-18 13:57
My OPI-PC seems to run fine @ 1200 Mhz (with heat sink)
Ran the cpuburn util for a while a few weeks ...

Running only cpuburn is useless if it's about data integrity. You would've to run 3 tasks cpuburn and one cpufreq-ljt-stress-test. And when data corruption occurs you know that you've to further decrease clockspeed or to increase voltage (negative for temperature and lifespan) to get reliable operating points.

How many hours/days did you let cpuburn run?

Does your 'headless server' run at 1.2 GHz @ 1.3V all the time or is cpufreq scaling default? There are only 2 operating points defined in the fex file so I'm curious what's happening if the H3 is idle. Normally it should both lower the clockspeed and the core voltage but since the dfvs table contains just 2 entries with insane high values (both beyond any sane definitions) I've no idea what's happening then.

Please compare with http://linux-sunxi.org/Cpufreq (would be also interesting how consumption differs when the H3 is idle at 'overclocking' speeds like 1.2GHz @ 1.3V or when it's operated in a sane clockspeed/voltage range, eg. 648Mhz @ 1.04V)

bronco

hojnikb replied at 2015-12-5 00:27
I suppose recommended minimums are meant for stable operation for even the crappiest quality bins.

...

You might run into stability problems. And the potential savings aren't worth the efforts.

It makes nearly no difference regarding consumption/temperature when you decrease voltage from 900mV to 800mV but it's a completely different story at the upper limit of the scale: 1400mV vs. 1500mV make a huge difference. By simply stopping this overvolting most of the heat/stability problems (and the need for a fan) are gone.

lymon

My OPI-PC seems to run fine @ 1200 Mhz (with heat sink)
Ran the cpuburn util for a while a few weeks ago and no failures came up.

At 1536 Mhz I had stability issues (I noticed this even without running cpuburn)....the OPI seemed to have random hick-ups at this speed.

I am now running it at 1200 for weeks and it has been running fine since then, although I am only using my OPI as a headless server.

hojnikb

Does Allwinner even specify a stable clock and voltage or is 1.6Ghz actually an overclock and the chipset itself is rated for less (like 1.0-1.2Ghz as its usual with cortex A7 designs). ?

bronco

hojnikb replied at 2015-11-18 16:13
Does Allwinner even specify a stable clock and voltage or is 1.6Ghz actually an overclock and the ch ...

They do not specify this. This "up to ..." stuff is pure marketing bullsh*t. Allwinner doesn't even care regarding processor features (see this press release here that's still online. The A83T is neither able to be clocked at 2.0 GHz nor does it implement big.LITTLE -- it's the usual chinese style of providing 'informations' and cpufreq/voltage stuff is not specified in the 'user manual' of the device in question, only 'recommended' voltage limits)

Again: http://linux-sunxi.org/Orange_Pi_PC#CPU_clock_speed_limit

The fex files used with H3 boards are set to 'extremity frequency' also regarding DRAM clock speeds: https://github.com/loboris/Orang ... ge/orange_pi_pc.fex

Here you find the datasheet: http://linux-sunxi.org/H3 (search for Table 9-2, the corresponding cpu clockspeeds depend on the device in question: which cooling approach has been used?).

For me it makes absolutely no sense to buy a rather slow device (Cortex A-7) to run it at high speeds to minimize lifespan and get stability and data integrity issues. When I start with H3 I will use something like this http://pastebin.com/Wa879G0Y, then adjust scaling_max_freq to 1008 MHz and walk through the available cpufreq governors to get an idea how the H3 behaves both thermally and regarding performance. I don't want a device that heats up and ruins its lifespan unnecessarily when idle (which it will be most of the time)

hojnikb

So basically, 1.53Ghz is really just an overclock and its not really designed to be stable at that frequency... Is that right ?

In that case, it would make sense to have all linux distros at 1.2Ghz and an option for 1.53Ghz.

bronco

hojnikb replied at 2015-11-18 23:36
1.53Ghz is really just an overclock and its not really designed to be stable at that frequency... Is that right ?

We (or let's better say the linux-sunxi community) do know that Allwinner's press releases where they claim new chips run with "up to ..." are just marketing chitchat. They don't care at all what's written therein since their main market are tablets or Android OTT boxes where customers like the feeling of having as many CPU cores as possible and the highest "up to" numbers written on the packaging. In recent datasheets and user manuals you won't find clockspeeds -- only recommended voltage ranges instead (understandably since it's not possible to give other recommendations due to the 'thermal design' of tablets and OTT boxes being responsible for maximum cpufreq scaling settings)

All we have are remarks like these that are present in some (all?) H3 fex files:

; extremity_freq(Hz): cpu extremity frequency when run benckmark or demo apk
;                     1536MHz@1500mV with radiator, 1296MHz@1340mV without radiator
; max_freq: cpu maximum frequency, based on Hz, can not be more than 1200MHz

And we have 'hardware reliability tests'. Unless you torture the H3 with real heavy workloads for hours/days and check data integrity it's not safe to exceed Allwinner's recommended maximum values for clockspeeds and voltages. And while you might be able to run your H3 safely with 1296 MHz and 600 MHz DRAM then this might not be true for someone else. We're talking about dirt-cheap SoCs and not expensive x86 CPUs. The last paragraphs are important when we're talking about SBCs: http://linux-sunxi.org/Cpufreq#.22Overclocking.22

When my Orange Pi PC arrives in a few weeks I will give it a try with default settings and since I do not plan to use an annoying fan and want to use the board as long as possible I will then try settings like these out: http://pastebin.com/kfScnPup (based on loboris' great work and just decreasing clockspeeds here and there down to more sane values. And also extending the dvfs table to let the SoC idle at 0.96V instead of 1.3V -- just an assumption that this happens now with only 2 operating points defined in the Orange Pi dvfs tables)

barquerito

as I installed ubuntu-mate in my orange-pi-pc,
I cut the mhz above, CPU h3, so that the CPU speed ranged from a minimum of 480 MHz up to the limit set by me, much more conservative than 1.6 GHz, I understood that this lengthened the life of the CPU. and I just hope that the graphics acceleration mali400 a reality.
if not orthodox method, just hope it works.

my /etc/rc.local:

#! / bin / sh -e
# rc.local
echo 1008000> / sys / devices / system / cpu / cpu0 / cpufreq / scaling_max_freq
echo 1008000> / sys / devices / system / cpu / cpu1 / cpufreq / scaling_max_freq
echo 1008000> / sys / devices / system / cpu / cpu2 / cpufreq / scaling_max_freq
echo 1008000> / sys / devices / system / cpu / CPU3 / cpufreq / scaling_max_freq
echo 0> / proc / sys / kernel / hung_task_timeout_secs
dmesg -n 1
exit 0

whitewind

barquerito replied at 2015-11-19 07:51
as I installed ubuntu-mate in my orange-pi-pc,
I cut the mhz above, CPU h3, so that the CPU speed ra ...

As I understand, all cores have the same settings:

1. readlink /sys/devices/system/cpu/cpu1/cpufreq
   
2. ../cpu0/cpufreq

Copy code

So, my rc.local looks like this:

1. echo 600000 > /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/userspace/set_freq
   
2. echo 1200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Copy code