RPi-Monitor for H3

hojnikb

How does one edit those frequencies ?

I was looking at script.bin and it doesn't look like that dvfs table above...

Is there any special way to alter those settings ?

bronco

hojnikb replied at 2015-11-28 06:12
How does one edit those frequencies ?

I was looking at script.bin and it doesn't look like that dvf ...

You need the sunxi-tools to convert fex file into script.bin and vice versa: It's explained here: http://www.orangepi.org/orangepi ... 7&fromuid=29411

Always make a backup of script.bin before converting back and ensure you're able to revert changes (since the 1st partition is VFAT formatted any device being able to read/write your SD-Card should suffice)

hojnikb

I see. Will give it a try and test it a bit...

More info the better i suppose.

hojnikb

bronco replied at 2015-11-28 05:29
The whole idea to 'overclock' is somewhat insane.

Anyway...

Looks like 1.18V@1.2Ghz might not be enough for every board out there.

Mine just hanged (screen froze) while upgrading the system and running midori in background.

bronco

hojnikb replied at 2015-11-28 21:01

Looks like 1.18V @ 1.2Ghz might not be enough for every board out there.

Thx for the feedback. My H3 had problems at the other end of the scale (I set scaling_max_freq to the lower 480 MHz limit in /etc/rc.local) below 0.9V but at 1.2 GHz I was able to decrease even more and while being still able to torture the H3 with cpuburn-a7 and cpufreq-ljt-stress-test without errors.

But a wide variation is to expected the way these dirt-cheap SoCs are made... And I should add that I used the OPi PC all the times headless (never connected a display), that might also make a difference -- will give a try later myself.

BTW: Testing different settings without also using cpuburn-a7 and cpufreq-ljt-stress-test to check stability and data integrity is a bit useless.

But still the good news is: Having a dvfs table with 7 entries you can increase voltages at the upper limit and still benefit from dramatically reduced consumption/heat in real-world scenarios with interactive/ondemand governor. Since then core voltage will only be adjusted to high levels when it's needed but when the CPU is idle (the state it's in most of the time) you benefit from low voltage/consumption and less heat

hojnikb

It seems that 1.24V@1.2Ghz is stable for me.

But its worth noting, that stressing the thing at 1.2Ghz@1.24V still yields ~80C after a couple of minutes. But it doesn't throttle, nor put put cores offline.
Although my environment is not ideal, since its really hot in here (~25C) + orange is in case with heatsink (but i did remove the top lid to allow for a little bit of airflow).

Still much better than stock config, where core offlining due to heat was costant.

Now we just need to figure out a script that would undervolt the thing as low as possible. But i guess that won't be trivial, since voltage can't be set on the fly. Or am i wrong ?

bronco

hojnikb replied at 2015-11-28 23:18

It seems that 1.24V @ 1.2Ghz is stable for me.

I made a test with connected display in the meantime. The H3 is a well-behaved SoC when configured for HDMI output: If there's no display detected the video engine will be shut down completely.

I used again loboris' settings to be able to reach the overvolted area also:



OPi was totally idle, I only adjusted cpufreq between 480MHz, 1200 MHz (both then @ 1.3V) and 1536 MHz (1.5V). Jumping between 1.2 and 1.53 GHz results in 3° more or less (1.3V vs. 1.5V). The 3°C more or less over the whole graph are just me switching the display on and off again. So it matters whether a display is connected or not and the settings posted yesterday might only work for headless systems (which is good news since there would be some room if it's really about overclocking server systems without connected display).

Next step: I'll remove the mali_extreme stuff from my adjusted fex file and test again headless to see how temperatures develop (these mali_extreme entries were not present in Xunlong's fex files as far as I know).

Regarding 'normal use' with connected display instead of headless it's obviously a good idea to start with Allwinner's recommended values as outlined here http://linux-sunxi.org/Orange_Pi_PC#CPU_clock_speed_limit and then start to decrease it while testing under worst case conditions.

BTW: Inside a small enclosure a heatsink isn't that useful. You will be able to compensate for peak performance/heat but under full load the surrounding temperature will increase all the time and then the heatsink can't help much any more.

bronco

Thx for reporting back. With connected display the values used before are useless and instabilities/crashes occur. I chose your upper value and adjusted the other OPPs:

1. extremity_freq = 1296000000
   
2. max_freq = 1200000000
   
3. min_freq = 480000000
   
4. LV_count = 7
   
5. LV1_freq = 1296000000
   
6. LV1_volt = 1320
   
7. LV2_freq = 1200000000
   
8. LV2_volt = 1240
   
9. LV3_freq = 1104000000
   
10. LV3_volt = 1180
    
11. LV4_freq = 1008000000
    
12. LV4_volt = 1140
    
13. LV5_freq = 960000000
    
14. LV5_volt = 1080
    
15. LV6_freq = 816000000
    
16. LV6_volt = 1020
    
17. LV7_freq = 480000000
    
18. LV7_volt = 980
    

Copy code

Again cpuburn-a7 and cpufreq-ljt-stress-test running in parallel. In the left values with connected display (~4.5°C more) on the right without.





I'll have to wait for the 2nd OPi PC to give it a try without heatsinks (for our use cases important to also check worst case thermal conditions). But as already said before: the H3 can shine when underclocked. With 504-720 MHz it's faster than an A20 and consumes also less power. This is the area we're interested in...

hojnikb

It would be interesting to find the most efficient frequency to run at. (same for other areas like dram, GPU...)
Basically best perf/watt.

So, voltage can't be adjusted on the fly ?

hojnikb

So, i've gotten an idea for auto undervolting...

Lets say you want to achieve the lowest stable voltage for 1.2Ghz and 480Mhz (lets ignore other frequencies for a minute, since they are not used as much anyway).

Start with a base, safe voltage (1340mV). Test it for a 10-15mins (just to be sure) and then lower the voltage -20mV by modifying the fex file (then compile to bin). Reset and repeat the process until it hangs (if that happens, revert back to working voltage and repeat stressing for longer). If its sucessful, you got yourself a low, stable voltage.
Repeat the same process for 480Mhz.

I think its doable with some shell scripting.