RPi-Monitor for H3

bronco

I made another test with even more undervolting. At 1.2 GHz consumption under full load doesn't exceed 3.0W and at 720 MHz we're already below 2W (with overvolted 'defaults' we speak about 3.5W at 1.2GHz and still 2.2W at 480 MHz)

In the following graph from left to right:

• conservative undervolting settings (for details see a few posts before, OPi PC script.bin here)
• experimental undervolting settings (won't share details since stability isn't confirmed yet)
• the usual overvolting approach all OS images for H3 OPi seem to share
  

Is this of any meaning to you? If you still believe you bought an ultra fast 1.6 GHz SBC and want to discuss the best fan/heatsink strategies then clearly no. If you're willing to accept what the H3 is and where it's able to shine then these are good news. Seems like the H3 is suited for low-power environments with sane dvfs settings. At 720 MHz for example its integer performance is better than a dual-core A20 @ 1.2 GHz while consuming only 2/3 of energy the A20 would need. This leaves also room for 'latency vs. performance' tuning when configuring kernel sources.

Next step will be to explore the area below 480 MHz. Are significant savings possible or is it ok to stay with 480-720 MHz (and allow a 'turbo boost' by adjusting scaling_max_freq up to 1.2 GHz if really needed)? We'll see.

makama80

@ bronco: I am still a believer. As said before somewhere else in this forum: my OPI H3 runs fine for 3-4 months now with the settings below. You can tune upper and lower frequency on any H3 board on the spot with this tool, off course limited by what's set in the kernel parameters. 1728 is not possible in my case, but it runs perfect on 1536. And to my humble knowledge that's not that far from 1600.

bronco

makama80 replied at 2015-11-27 18:34
@ bronco: I am still a believer. As said before somewhere else in this forum: my OPI H3 runs fine fo ...

I'm perfectly fine with people choosing rather slow SoCs just to try to fry them with overclocking/overvolting. It doesn't make any sense at all (especially burning a SoC at high voltage when it's most of the times idle and simply doing nothing) but if someone needs the feeling to have the fastest toy around... why not?
I document the stuff here for others that want to use the H3 for serious stuff. And then you follow the usual approach (every responsible hardware vendor does normally before releasing a product based on an ARM SoC) and check sane limits. You start with a set of operating points (cpufreq/voltage correlations), use heavy workloads and check simultaneously both stability and data integrity (worst case scenarios). And then you iteratively decrease voltages unless stability/integrity is concerned. To get a dvfs table in the end that uses the lowest core voltages possible since it's just moronic to waste energy, increase heat unnecessarily and decrease the achievable lifespan of your device.

But there's no need to discuss that. Overclocking fanatics and people that want to do something serious with the hardware (have a look at this example in case of interest) are different groups that have nothing in common.

BTW: How many of you overclocking fanatics already tested worst case scenarios? Exactly none. But why do you fry your device at upper clockspeeds then? When you don't need the performance since you never checked whether it still works reliable when overclocked beyond sane limits?

Please answer: who of you already ran lima-memtester and both cpuburn-a7 and cpufreq-ljt-stress-test with your overclocked settings? To confirm they really work? No one, right? But you still fry your device idling around at a core voltage of 1.5V so that the H3 'needs' a heatsink or even a fan to not overheat even when DOING NOTHING at this overvolted settings.

bronco

Last try to outline the origin of the problem. It's not temperatures alone, it's overvolting.

This is an H3 with heatsink idling with 480 MHz @ 1.04V:




This is the very same H3 with loboris' default settings idling with 1.53 GHz @ 1.5V only 5 minutes later:



They do exactly the same: NOTHING. That's what CPUs do most of the time. They are sitting there and waiting. And while it doesn't make that much difference whether a 'modern' Cortex-A7 CPU idles at high or low clockspeeds the difference is the used voltage. And the 'factory settings' all H3 images seem to use are overvolted (necessary to provide realible overclocking).

But since you don't need that high CPU clockspeeds in reality and no one ever confirmed that they really work reliable (they're still way too slow for the stuff that normally runs on cheap ARM devices -- all the magic happens in different regions of the SoC: GPU/VPU!!!) it simply makes no sense at all to fry your device with overvolted settings all the time. It's just a waste of energy and efforts (active cooling).

This is the very same H3 with interactive governor and therefore idling with 480 MHz @ ~1.3V -- compare with the 1.04V settings above!



If you live in the northern hemisphere then at least these days this makes some sense: It helps heating your room.

nematocyst

Your data does suggest that the default settings at idle result in significant over-voltage and thus higher than needed temperatures.  It's been over a week for me, but I didn't experience this, if I remember correctly.  I just assumed the sparse dvfs table mapped over some built in values when LVx_freq was 0.  But there's no good reason not to use a correct table.

I think the script.bin files that are linked to and present in the d/l images ought to have correct tables.  You can still overclock exactly the same way by setting the default freq to 1536, but you get proper voltages when you either manually adjust the maximum at run-time, or when the chip decides to idle.  Seems crazy to not have a fully correct table-- 8 values is more than sufficient.

bronco

nematocyst replied at 2015-11-28 00:25
Your data does suggest that the default settings at idle result in significant over-voltage and thus ...

I don't know the 'history' of the dvfs settings, just by looking into different sources here and there it seems like it's possible to get a clue who started overclocking/overvolting when.

1) Sane settings in the beginning

According to the linux-sunxi wiki this is somewhat  'Allwinner's SDK' (provided by Tronsmart for their Draco H3 TV box).

Settings therein: (no overclocking and no overvolting, just sane settings that could probably be a bit lower but are OK):

1. boot_clock      = 1008
   
2. max_freq = 1200000000
   
3. min_freq = 480000000
   
4. boot_freq = 1008000000
   
5. LV_count = 8
   
6. LV1_freq = 1200000000
   
7. LV1_volt = 1300
   
8. LV2_freq = 1008000000
   
9. LV2_volt = 1200
   
10. [no more working entries]

Copy code

2) Overvolting/overclocking done by Xunlong

Again according to the linux-sunxi wiki when Xunlong started it was already overclocked and massively overvolted. BTW: This is really just copy&paste from the fex file inside Xunlong's Android image, the commented values are not from me but are an indication that the person adjusting that increased the values already present in the fex file:

1. #boot_clock           = 1008
   
2. boot_clock           = 1200
   
3. #max_freq = 1200000000
   
4. max_freq = 1536000000
   
5. min_freq = 480000000
   
6. LV_count = 8
   
7. #LV1_freq = 1200000000
   
8. LV1_freq = 1536000000
   
9. #LV1_volt = 1300
   
10. LV1_volt = 1500
    
11. #LV2_freq = 1008000000
    
12. LV2_freq = 1200000000
    
13. #LV2_volt = 1200
    
14. LV2_volt = 1300
    
15. [no more working entries]

Copy code

3) Even more overclocking?

The only difference with loboris' settings is that he also again increased boot_clock, defines also extremity_freq for the CPU cores and added a MALI section with extreme values:

1. #boot_clock           = 1008
   
2. #boot_clock           = 1200
   
3. boot_clock           = 1536
   
4. extremity_freq = 1536000000
   
5. 
   
6. [mali_para]
   
7. mali_used = 1
   
8. mali_clkdiv = 1
   
9. mali_extreme_freq = 600
   
10. mali_extreme_vol = 1400

Copy code

That means only 2 OPPs are defined with one above 1.2 GHz using the extreme voltage of 1.5V and the other with 1.3V that might be used for all lower clockspeeds. And in my tests it made exactly no difference regarding temperature (again: temperature depends on core voltage) when the H3 idled at 1.2 GHz or 480 MHz --> same voltage for those cpufreqs. When you use the performance governor then it idles at 1.53 GHz and therefore 1.5V will be used (0.1V more than recommended/allowed!). And the temperature of a completely idle SoC increases by more than 10°C compared to reasonable settings (without heatsink it would be even more!). In this state the CPU cores do NOTHING. There is no need to fry a chip that's doing nothing. It's just moronic to do it this way.

4) Possible solutions?

4.1) Boot clock

I've no idea why one would like to adjust this value. The SY8106A voltage regulator is set to 1.2V at boot which should be safe to deal with 1008 MHz.

4.2) Defining a dvfs table providing more and especially better entries

Using a dvfs table that contains more values (and not illegal ones above the upper recommended limit but reasonable ones -- that means "voltage as less as possible until stability is concerned") then most of the thermal issues would automagically disappear. Simply by using a cpufreq governor != performance and adding a few lower values to the table. People could still use peak performance at 1.53 GHz but could start to throw away their fans. But it seems no one likes the idea since 'overclocking is cool'?

I've no idea why nobody chose to add more sane dvfs entries so far. Ok, I've two assumptions:

• Normally it's the device's manufacturer that walks through this stuffs and provides a tested dvfs table containing the lowest voltage values possible. But since Xunlong decided to advertise a 1.2 GHz SoC as being capable of "up to 1.6 GHz" (maybe only to justify the "plus" in the name of the first H3 based OPi?) and therefore needed insane overvolting this was obviously neither the case nor the intention.
• The code responsible for parsing the dvfs table in the old Allwinner kernel seems to be broken somewhat. I tried different settings with more than 8 entries that all failed more or less. Now I have a working table ready to be optimised in an automatic fashion (a script will start with my master table and then walks through every possible setting and decreases voltage unless the first error occurs -- that might take a few days but when my 2nd OPi PC arrives it's his job to do this unattended on its own)
  

4.3) Who should care?

That some people like the impression running an "up to 1.6 GHz" SBC is one thing. But the other is that due to those weird dvfs settings this is the root cause not just for the thermal issues most users have but also again and again stability issues as described here: http://www.orangepi.org/orangepi ... age=2&fromuid=29411

I'm perfectly fine with people trying to waste energy as much as possible and fry their devices even when idle. But since this is nothing for me or others that don't want to use the H3 the 'pimp my ride' style but let it do some work in an energy efficient way, I provide some little insights and a probably helpful tool to get the idea what's wrong with all H3 OS images: Wrong/missing dvfs table entries leading to heat/stability problems especially when used together with wrong cpufreq governors (performance in this case -- with sane dvfs table entries always a good idea, with the entries currently used a nightmare).

nematocyst

I think we're in agreement-- get script.bin files using proper dvfs tables.

I doubt most are really of the  "overclocking is cool" camp.   A heatsink and/or fan will appear to solve the heat issue, so investigation ceases.  Personally I think a sticky with brief explaination/solutions would help.  But mention of dvfs and overclocking in half a dozen threads is likely just confusing.  A throurough analysis as you have done is great, even appreciated.  But I suspect most people just want a working device as quickly as possible without having to understand all the details.

bronco

nematocyst replied at 2015-11-28 02:29
I doubt most are really of the  "overclocking is cool" camp.

Most feedback I already received was just 'I use a fan, I love being able to clock this little thing with 1.53 or better 1.72 GHz, temperature is ok, go away' :-)

And most of the heat issues are simply handmade. Look at the Openelec thread. They use the performance governor together with the default script.bin (that means increasing the SoC's consumption by more than 0.3W and the temp unnecessarily by ~10°C even if it's doing NOTHING) and wonder why they all need heatsinks and have their devices running at 75°C. It's crazy stuff that happens here...

Anyway, I started the thread back when my OPi PC didn't arrived. I wanted some informations that I didn't got. And now I have the device, am happy that I don't need to fry it and just provide some informations on this topic. Unless people like Steven or loboris don't pick this up nothing will change.

When my 2nd OPi PC arrives I will start testing sane dvfs values and then get back to this thread and ask whether others are willing to test. Since the problem is: We're not talking about "CPUs" that are extensively tested when leaving production but dirt-cheap ARM SoCs for consumer devices instead. All I've written here applies especially to ultra-cheap SoCs like the H3: http://linux-sunxi.org/Cpufreq#.22Overclocking.22 (settings that might work perfectly on the 2 H3 devices I own might lead to problems on another's SoC. Feedback welcome)

hojnikb

i wonder how low can you undervolt the thing by still retaining a mild overclock.
will defenetly give it a go!

bronco

hojnikb replied at 2015-11-28 04:47
i wonder how low can you undervolt the thing by still retaining a mild overclock.
will defenetly giv ...

The whole idea to 'overclock' is somewhat insane.

Anyway...

We did some tests the last 36 hours and ended up with these settings now (preliminary since I'll have to wait for my 2nd OPi PC to give it a try without heatsink). We rely on loboris' fex file and only the following has been adjusted:

1. boot_clock = 1008
   
2. 
   
3. [dvfs_table]
   
4. pmuic_type = 2
   
5. pmu_gpio0 = port:PL06<1><1><2><1>
   
6. pmu_level0 = 11300
   
7. pmu_level1 = 576
   
8. extremity_freq = 1296000000
   
9. max_freq = 1200000000
   
10. min_freq = 480000000
    
11. LV_count = 7
    
12. LV1_freq = 1296000000
    
13. LV1_volt = 1320
    
14. LV2_freq = 1200000000
    
15. LV2_volt = 1180
    
16. LV3_freq = 1104000000
    
17. LV3_volt = 1120
    
18. LV4_freq = 1008000000
    
19. LV4_volt = 1080
    
20. LV5_freq = 960000000
    
21. LV5_volt = 1020
    
22. LV6_freq = 816000000
    
23. LV6_volt = 960
    
24. LV7_freq = 480000000
    
25. LV7_volt = 920

Copy code

Further voltage decrease doesn't make that much sense. And with this setup you can fully utilise the SoC on all 4 cores at 1.2 GHz without exceeding 60°C (heatsink applied) or 40°C when idle. Taking ambient temperature into account that means:

• 17°C above ambient when idle
• 37°C above ambient under full load (verified with cpuburn-a7 on all cores and cpufreq-ljt-stress-test running simultaneously)
  

H3 users relying on 'default settings' fry their device while being not able to benefit from these dumb settings at all (unless they play 'high performance computing' for which the H3 is not the best suited device). The performance of the H3 is still the same regardless whether one uses dumb dvfs settings that lead to 30 or even more °C more or sane ones that help the device staying cool. It's just about adjusting dvfs settings and refrain vom overvolting a rather slow SoC.

Anyone able to deal with sunxi-tools is welcome to give the above settings a try and report back. Thx