RPi-Monitor for H3

hojnikb · Published in 2015-11-26 23:23:31

I don't think Orange team did the overclock themselfs, just probably just used what allwinner provided for best antutu results.

But still, it would be great if we had a proven dvfs table with sane voltages and frequencies.

Also, whats the story on DRAM, does it cause overheating or not ?

bronco · Published in 2015-11-26 23:31:59

hojnikb replied at 2015-11-26 23:23
I don't think Orange team did the overclock themselfs, just probably just used what allwinner provid ...

DRAM clockspeed has nearly no influence, it's overvolting/overclocking: http://www.orangepi.org/orangepi ... 0&fromuid=29411

My 1st OPi PC arrived two hours ago, I started with loboris' Vivid Mate image for the OPi PC and all I did was to adjust the script.bin shipped with the following settings:

boot_clock = 1008
[dvfs_table]
pmuic_type = 2
pmu_gpio0 = port:PL06<1><1><2><1>
pmu_level0 = 11300
pmu_level1 = 576
;extremity_freq = 1536000000
max_freq = 1200000000
min_freq = 480000000
LV_count = 7
LV1_freq = 1200000000
LV1_volt = 1320
LV2_freq = 1104000000
LV2_volt = 1250
LV3_freq = 1008000000
LV3_volt = 1200
LV4_freq = 960000000
LV4_volt = 1160
LV5_freq = 816000000
LV5_volt = 1100
LV6_freq = 540000000
LV6_volt = 1040
LV7_freq = 480000000
LV7_volt = 1040

Copy code

I had lower values before but the board didn't boot. Just to realize I used a faulty SD-card. Now I'm doing the same stuff again with a good and fast SanDisk TF card and will report back.

bronco · Published in 2015-11-27 03:23:53

Edited by bronco at 2015-11-27 04:03

bronco replied at 2015-11-26 23:31
DRAM clockspeed has nearly no influence, it's overvolting/overclocking: http://www.orangepi.org/or ...

First results. I used loboris' great OrangePI-PC_Ubuntu_Vivid_Mate.img for my OPi PC. I started without heatsink and the board lying flat on the table. Later I attached a 19x19mm heatsink (using adhesive tape) and use convection which led to 10°C less under full load and no throttling at 1.2 GHz anymore.

Since I'm not an overclocker I limited all tests to not exceed 1.2 GHz. The first run of tests (running sysbench starting with the highest cpufreq and decreasing it until 480 MHz [1] afterwards being idle and continually increasing cpufreq again) happened with unmodified settings starting at 18:10, the second run with the adjusted values from above after a restart with exchanged script.bin at 18:56:

The following are the obvious results:

When running with loboris' unchanged settings (only 2 dvfs entries: 1.53 GHz @ 1.5V and 1.2 GHz @ 1.3V) obviously at all cpufreq steps the core voltage stays at 1.3V (look at the idle values between 18:45 and 18:55: temperature and therefore consumption remains)
With my settings it seems worse in the beginning (5°V above loboris' settings at 1.2GHz) and obviously dvfs is working and the less core voltage is used the lower the cpufreq (look at the idle values starting from 19:25: between 41°C and 44°C depending on cpufreq switching between 480MHz and 1.2GHz
Good news: It makes not that much difference whether the system idles at 480 MHz or 1.2 GHz. With loboris' fixed core voltage there's no difference at all, with my settings and core voltage jumping between 1040mV and 1320mV the difference is just 2-3°C or 0.2mW
Using sane dvfs values it might be an idea to simply stay with the performance governor. If you're interested in details: http://linux-sunxi.org/Cpufreq#The_.22performance.22_governor
Using insane dvfs values (as it's the case with all H3 OPi images) using the performance governor is a really bad idea since then the core voltage will always be 1.5V (which exceeds the maximum 1.4V that are allowed according to the H3's user manual) which leads to all sorts of thermal troubles.

The next question is: Why do I get worse thermal results at 1.2 GHz compared to loboris' settings? Possible answer: I'm using 20mV more here (relying on the recommended voltage settings). Might these 20mV be responsible for a whopping 5°C more? We'll see.

[1] Test-Skript used:

echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
for i in 1200000 1200000 1104000 1008000 912000 720000 480000 ; do
echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4
done
for i in 480000 720000 912000 1008000 1104000 1200000 1200000 ; do
echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
sleep 120
done

Copy code

Results depending on clock speed:

480 MHz: 398.1 sec.
720 MHz: 264.3 sec.
912 MHz: 208.6 sec.
1008 MHz: 188.6 sec.
1104 MHz: 172.1 sec.
1200 MHz: 158.2 sec.

Copy code

Regarding single threaded performance the H3 running at 1.2 GHz is roughly comparable to an older i-MX6 running at 1.0 GHz or an A20 running at 1.1 GHz:

bronco · Published in 2015-11-27 05:18:52

Edited by bronco at 2015-11-27 06:54

bronco replied at 2015-11-27 03:23
Might these 20mV be responsible for a whopping 5°C more?

Nope, that doesn't the trick. I exceeded 71°C again at 1.2 GHz so there's some work to do to get a clue how the dvfs table entries are used in reality (but I doubt it's worth the efforts -- let's have a look how the linux-sunxi devs implement that stuff in mainline kernel)
I re-ran the test setup twice, the second time with reduced DRAM clock:

[ 66.870649] [ddrfreq] DDR: 672000KHz->480000KHz start
[ 66.870664] [ddrfreq] current cpu is cpu1
[ 66.871859] [ddrfreq] elapsed: 1046us
[ 66.871876] [ddrfreq] DDR: 672000KHz->480000KHz ok!

Copy code

Makes no difference at all, also sysbench results remained identical. The first run is with DRAM @ 672 MHz, the second with 480 MHz:

I made another test: when being idle @ 504 MHz consumption is at 1.5W, when running the sysbench test also with 504 MHz it's 0.4W or 3-4°C above. And performance nearly identical with a dual-core A20 @ 960 MHz. Shutting down CPU cores just helps a little but isn't worth the efforts.

When my 2nd OPi PC arrives in a few days, then I will start to iteratively lower core voltages and check stability and data integrity using lima-memtester, cpufreq-ljt-stress-test and cpuburn-a7. For now I'm done. It's obvious that the H3 operates a little hotter than the A20 for example. But the heat/stability problems Orange Pi users suffer from are just a result of overclocking/overvolting.

If you're able to accept that the H3 is just a normal boring old Cortex-A7 design running at 1-1.2 GHz then there's no nead for active cooling and not even for a heatsink.

If you want to escape the overvolting hell, think about adjusting your script.bin. Mine for OPi PC can be found here.

bronco · Published in 2015-11-27 05:37:27

hojnikb replied at 2015-11-26 23:23
I don't think Orange team did the overclock themselfs, just probably just used what allwinner provid ...

I don't think so: http://www.orangepi.org/orangepi ... d=166&page=1#pid857

Every available H3 OTT box is advertised as and runs with 1.2 GHz. Only Xunlong promoted these devices as being capable to run at 1.6 GHz and adjusted settings in the fex files: http://linux-sunxi.org/Xunlong_Orange_Pi_2#Manual_build -- there this totally insane overclocking/overvolting stuff originates from.

fritz · Published in 2015-11-27 05:47:30

Actualy I have with mainline and THS-patches from @Josef Gajdusek:

[root@alarm ~]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
28099

It's a first step, but it's to early to make some tests.

bronco · Published in 2015-11-27 06:06:52

fritz replied at 2015-11-27 05:47

cat /sys/devices/virtual/thermal/thermal_zone0/temp
28099

Thx for the follow-up. But I never trust these read-outs unless verified extensively. With A20 we had the situation with kernel 4.0 or 4.1 that the SoC's internal temperature was below ambient temperature which is obviously not possible (and the driver for sunxi's old 3.4 kernel was also somewhat strange/wrong).

Therefore time will tell. But for now it's obvious that all the heat and stability problems the OPi forums are full of originate in overclocking and especially overvolting (the latter necessary to do the former).

If the H3 is used as intended (a low-end SoC suitable for chinese market demands, that can be clocked up to 1.2 GHz), then everything's alright. And that's good news at least for me.

Fun fact: Today not only my OPi PC arrived but also the new $5 RPi Zero was announced: http://www.cnx-software.com/2015 ... -bcm2835-processor/ -- combine this with crappy USB-Ethernet and you get all I need for half the price of an OPi PC. "Fortunately" they saved the RPi's camera connector so OPi PC is still in the game...

bronco · Published in 2015-11-27 06:40:47

Edited by bronco at 2015-11-27 06:43

Last sysbench test for today to get an idea how the H3 behaves as low-power device with its 4 ARM cores. I compared 1 active core @ 1.2 GHz vs. 4 cores @ 504 MHz: the quad-core setup consumes 0.3W and 1°C less and is also way faster (379 seconds vs. 649 seconds -- at the same consumption level the quad-core approach would be over two times faster!).

Wow, I didn't thought that before that a quad-core design wins also when it's about performance vs. consumption.

That's great news: The H3 with its quad-core makes sense when it's about IoT and such low-power stuff. Details left as an exercise for the reader (with this thread you have the approriate set of tools to get a clue)

Disclaimer: Yes, I know that ~100% of all benchmarks lead to wrong assumptions

bronco · Published in 2015-11-27 08:14:47

Edited by bronco at 2015-11-27 08:24

Sneak preview for all of you tired of overheating. I just started with 'undervolting':

extremity_freq = 1296000000
max_freq = 1200000000
min_freq = 480000000
LV_count = 7
LV1_freq = 1200000000
LV1_volt = 1240
LV2_freq = 1104000000
LV2_volt = 1200
LV3_freq = 1008000000
LV3_volt = 1160
LV4_freq = 960000000
LV4_volt = 1100
LV5_freq = 816000000
LV5_volt = 1040
LV6_freq = 540000000
LV6_volt = 1000
LV7_freq = 480000000
LV7_volt = 960

Copy code

One cpuburn-a7 task utilising all 4 CPU cores simultaneously and then cpufreq-ljt-stress-test checking stability and data integrity. I started with the normal settings, then stopped at 0:52, replaced script.bin with undervolted settings and restarted:

80mV less at 1.2GHz mean 10°C less under full load

And results look good also:

Testing CPU 0
1536 MHz SKIPPED
1440 MHz SKIPPED
1344 MHz SKIPPED
1200 MHz ............................................................ OK
1104 MHz ............................................................ OK
1008 MHz ............................................................ OK
912 MHz ............................................................ OK
816 MHz ............................................................ OK
720 MHz ............................................................ OK
648 MHz ............................................................ OK
600 MHz ............................................................ OK
504 MHz ............................................................ OK
480 MHz ............................................................ OK
408 MHz SKIPPED
312 MHz SKIPPED
240 MHz SKIPPED
120 MHz SKIPPED
60 MHz SKIPPED

Copy code

When my 2nd OPi PC arrrives I will automate these tests to get stable settings with as less voltage as possible...

bronco · Published in 2015-11-27 09:16:59

Undervolting successful (no errors reported by cpufreq-ljt-stress-test while running cpuburn-a7).

Before (official OPi PC settings):

And after (core voltage lowered but exactly same performance at every cpu frequency):