Operating the H3 in a reliable way (sane clockspeeds)

bronco

hojnikb replied at 2015-12-4 16:07
Is it possible to go lower with the voltage ?
Something like 800mV for 240Mhz.

Maybe this works. But it's already below the recommended minimum according to the user manual. And it doesn't help that much with further savings.

The other end of the scale is more interesting since a slight increase in voltage leads to massively more consumption/heat. I can't explain it well since I'm an electrics NOOB so better read from here on: https://olimex.wordpress.com/201 ... -way/#comment-20385

And this is exactly the reason the Orange Pi Plus/2/PC users suffer from heat problems: Since the dvfs settings used with every OS image are broken: Only 2 voltages defined, the upper beyond specifications (1.5V) and the lower also on the upper limit (1.3V). By simply adjusting these to sane values und using a few more dvfs table entries all the problems are gone.

And for my use cases the H3's 4 cores are great since you can operate the SoC at low clockspeeds (then also low voltages) what really helps lowering consumption/heat. This is where the H3 can really shine: http://www.orangepi.org/orangepi ... 6&fromuid=29411

hojnikb

I suppose recommended minimums are meant for stable operation for even the crappiest quality bins.

But the bigger question is whenever it actually sets 800mV if you define it in the dvfs table or just ignores it and sets the recommended minimum.

Defenetly needs testing.

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.

bronco

A few final words: http://linux-sunxi.org/User_talk ... e_Frequency_Scaling

I let the test script also walk through my 'headless' settings with further reduced voltage (on the right):



It's not worth the efforts to undervolt further. The most important change is to escape from Xunlong's overvolted dvfs table with only 2 entries leading to all sorts of heat/stability problems the forum is full of.

zgoda

Thank you for your work. Stability is my main concern so I will definitely follow your advice.

OPi PC will be working in my beer cellar, any additional heat dissipation is not welcome.

bronco

zgoda replied at 2015-12-8 00:23
OPi PC will be working in my beer cellar, any additional heat dissipation is not welcome.

Today my 2nd OPi PC arrived and I had the chance to try again without a heatsink: It's crazy how these moronic dvfs table settings then look. On the left the 'defaults' with only 1.3V for all lower cpufreqs and 1.5V above 1.2 GHz defined. On the right sane settings:


Results without a heatsink, no enclosure (!) and upright position (helps a little bit due to convection):

Xunlong settings:
Idle at 480MHz/1300mV: 1.7 W consumption and 48°C
Idle at 1536MHz/1500mV: 2.1 W consumption and 60°C

Sane settings:
Idle at 480MHz/980mV: 1.5W consumption and 43°C
Idle at 1200MHz/1240mV: 1.6W consumption and 47°C


Given you combine the wrong dvfs settings (Xunlong's) with the performance governor you end up with a device that doesn't idle at 43°C but at 17°C more. While consuming a whopping 0.6W more. Still DOING NOTHING. That's the price you pay for accepting these weird overvolted/overclocked settings. It's obvious based on the graphs where the heat problem originates: Overvolting.

And given you put your H3 device into a small enclosure it might be easily possible that idle temperature exceed 70°C or even more. Still while being completely idle

At the moment I let the test script walk through my undervolted settings (not recommended since they're not expected to work with a connected display) and then I repeat the whole series of tests also firing up cpuburn-a7 to get an idea how fast throttling occurs without heatsink with Xunlong's insane default vs. sane settings...

hojnikb

Will you share the script for others to test ?

bronco

hojnikb replied at 2015-12-8 02:25
Will you share the script for others to test ?

Of course. I saved it as /usr/local/bin/check-temperature.sh

1. #!/bin/bash
   
2. 
   
3. FexSetting1=/media/boot/script.bin.OPI-PC_1080p60
   
4. FexSetting2=/media/boot/script.bin-display
   
5. 
   
6. diff /media/boot/script.bin ${FexSetting1} >/dev/null 2>&1
   
7. case $? in
   
8.         0)
   
9.                 cat ${FexSetting2} >/media/boot/script.bin
   
10.                 ;;
    
11.         *)
    
12.                 cat ${FexSetting1} >/media/boot/script.bin
    
13.                 ;;
    
14. esac
    
15. 
    
16. i=480000
    
17. echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    
18. echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    
19. echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    
20. sleep $(( 15 * 60 ))
    
21. 
    
22. read Maximum </sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
    
23. while [ $i -le ${Maximum} ]; do echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq; echo $i; sleep 6; i=$(( $i + 2400 )); done
    
24. sleep 300
    
25. cpuburn-a7 &
    
26. sleep 300
    
27. while [ $i -gt 480000 ]; do echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq; echo $i; sleep 6; i=$(( $i - 2400 )); done
    
28. pkill cpuburn-a7
    
29. sleep 300
    
30. shutdown -r now

Copy code

It's called from within /etc/rc.local this way (the trailing " &" is important):

1. /usr/local/bin/check-temperature.sh &

Copy code

(ensure that "exit 0" follows later in /etc/rc.local).

The "sleep $(( 15 * 60 ))" statement ensures that 15 minutes after a reboot nothing happens (this is necessary to get correct thermal measurements when running the board headless, since the display controller will be activated after a hot or cold boot and disables itself after 10 minutes -- in case you use this with an active display you can lower the amount of time to 5 minutes). And then the script walks through all cpufrequencies starting from 480 MHz.

The 2 script.bin files containing different dvfs settings MUST exist and will be referenced through $FexSetting1 and $FexSetting2. Be careful. This is just a quick&dirty hack above. If the files you specify here don't exist, script.bin will be deleted and the next boot impossible!

bronco

And you'll need cpuburn-a7 somewhere in your $PATH.

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.