Operating the H3 in a reliable way (sane clockspeeds)

bronco

For changes to take effect it would be necessary that you're using an image utilising script.bin and therefore you would've to use bin2fex/fex2bin to alter the contents. But please don't do this if you're not experienced and do a backup of your whole SD-card before. When editing/exchanging this stuff goes wrong then your board won't boot any longer.

Altering scaling_max_freq currently might not make a difference based on the assumption that only the 2 operating points in the fex file are used. But I had a look into the H3's SDK sources before and maybe the stuff in the dfvs table provided in the fex file only overwrites parts of the default table (that seems to use 1.2V for all frequencies). At the moment these are just wild assumptions and unfortunately I can not check myself since my H3 devices just left Shenzen.

That's why I started another thread and posted a preliminary RPi-Monitor template suitable to visualize relationships. According to Olimex reducing the DRAM bandwidth helps much with reducing the heat the H3 produces. Then it would be an easy one to try this out (and that's why I wrote the H3 template for RPi-Monitor). Adjust DRAM frequency by eg.

1. echo 480000 >/sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/cur_freq

Copy code

and have a look how temperatures change in different situations (while being idle, while running sysbench an all 4 or just 2 cores). That's the stuff I want to do when my Orange Pi arrives. But my main focus is underclocking to the limits. I had the fear the H3 would be broken by design and would consume many times as much as the A20 for example. But fortunately this is not the case :-)

bronco

nematocyst replied at 2015-11-21 23:29
wouldn't it be best to create a complete correct dvfs table that includes overclocked values such as 1536, 1296 frequencies, and then adjust scaling_max_freq at boot to whatever you feel comfortable with based on needs and cooling

Yes, that would be possible. I played recently with another board (LeMaker guitar, unfortunately not worth a look) that uses Actions Semi's S500 SoC. This beast and its PMU get really hot, exceeding easily 100°C. But there it was possible to define operating points in the sources to be able to clock the board up to 1.3 GHz (somewhat insane since then thermal throttling jumped in and the board became slower) and define a default of 1.1 GHz unless the user adjusted the value to his needs.

So it's possible to provide a dvfs table that starts at 480 MHz @ 1.04V (maybe even lower) and ends at 1536 MHz @ 1.5V (VDD_CPUX -- this is solely for 'extremity frequency when run benckmark or demo apk' not for normal use -- there the maximum rating is 1.4V and I really doubt that you can then run the SoC with 1.53 GHz).

The problem is to define the operating points in a sane way and test all these intensively. Since normally you try to define every operating point with lowest voltage possible to reduce both heat and consumption since even slight increases in voltage lead to a huge increase in both consumption/temperature. At least that's my goal with the OPi PC. Fortunately you can run all this stuff unattended, so I will set up a test environment to walk through a few hundred settings (with reboots in between -- did that already to test some u-boot settings to optimise network throughput on A20 boards)

nematocyst

Thanks.  I didn't know how all that worked.  I've built the sunxi-tools and created a new script.bin with such a table.  Operating at 1296 instead of 1536 (presumably 1.34v, according to the table i built) has already a noticeable effect on my temperatures.  Mostly I'm trying to find where I want to run at this point.  I just want to run all 4 cores at 100% reliably without resorting to active cooling.  I suspect I've alread achieved that (using a 1.5" heatsink), but I'll do more testing.

bronco

nematocyst replied at 2015-11-22 00:45
I suspect I've alread achieved that (using a 1.5" heatsink), but I'll do more testing.

Using RPi-Monitor (or something similar you would've to adjust for H3 first) really helps with stuff like that. Please keep in mind that some of the stuff you try to have an eye on works in a very dynamic fashion (cpufrequency scaling, throttling and even CPU cores being shut down for thermal reasons).
Couldn't believe it before using RPi-Monitor the first time on a Banana Pi... but you get so many relationships that normally stay invisible or would be hard to check by just looking at graphs. And I would have an eye on DRAM frequency whether reducing the frequency there further helps.

And if you also double check with a small set of benchmarks then you also get the idea what you trade in for what (peak performance against chip temperatures)

nematocyst

My box is going to run a chess engine 24/7.  I get a good idea of the trade just looking at the nodes per second (nps) achieved.  It actually runs fine with 1 core at 100% on the default (overclocked @ 1.536) settings.  With 2 cores at 1536, temps start to get troublesome, approaching 70C.  This is all with a heatsink-- without one, even 1 core at default OrangePi settings causes CPU shutdowns.

I'm not sure what to do wrt heatsinks though.  I have a few lying around from old computers.  They are designed for northbridge or video card cooling maybe 10 years ago.  The one I'm using isn't perfect.   It is all copper, but it doesn't contact the H3 perfectly because it's larger than the H3 and other stuff interferes.  Basically the RAM chips aren't at exactly the same height, so the heatsink isn't contacting snugly on that side of the H3 chip.  I know this only because in messing with it a few times, the residual grease left on the heatsink isn't a square like you'd expect.  It's most prominent on the side away from the RAM chips.  Anyway, I've ordered other heatsinks, and I won't fully decide how to run until I can test them.

bronco

There exist two problems with heatsinks:

• Contact to the chip's surface. If there's a problem (wrong adhesive tape, gaps between heatsink and surface) a heatsink might not help at all or even lead to increased temperatures
• Airflow around. If that's not possible a heatsink won't help at all. Compare with the heatsink and enclosure here: If the board is outside the enclosure the heatsink might help, inside it's a waste of efforts.
  

The two reasons above lead to many Orange Pi H3 users using an additional fan.


You learn that if you use the right instruments (again RPi-Monitor or something like that) and compare before/after. I made many tests regarding heatsinks and found a combination of thermal paste and SMD heatsinks with the best performance. Then I tried to use that in a different device with not that much space (airflow) inside just to realize that the heatsink prevented additional airflow and that temperatures without heatsink were lower since then convection jumped in. That's the result of really looking into it instead of relying on wrong assumptions ("heatsinks always help in any situation", "that H3 device has to be that hot" and so on)

And still the solution is to accept that Allwinner never produced SoCs for OTT boxes with Cortex-A7 cores that are able to be clocked somewhere near 1.3 GHz or even above. Adjust dvfs settings (no overclocking and especially overvolting any longer) and you're done.

hojnikb

Could you make a script, that applies safe/sane clockspeeds for linux distros, that are available.

I'd like to try that, but i dont want to end up with a non bootable system.

bronco

hojnikb replied at 2015-11-22 21:04
Could you make a script, that applies safe/sane clockspeeds for linux distros, that are available.

...

Fortunately this has nothing do with different Linux distros, it's just replacing script.bin and adjusting userland stuff (sysfs). When my OPi PCs arrive I will try to create a sane 'dynamic voltage frequency scaling' (dvfs) table (from 108 MHz up to 1200 in 10 steps, so that overclockers can still rely on this and add additional 6 operating points to heat their rooms). But this will take some time since the boards will have to run tests again and again, replace script.bin automatically, reboot and do the tests again.

I'll report back when finished, in the meantime the "RPi-Monitor" thread might be worth a look if fritz will supply the output of the test script I suggested (please keep in mind: If he's using the default dvfs with only high voltages and only 2 operating points defined then it might not look sufficient). But time will tell...

bronco

To finish this chapter. I came up with dvfs settings that work here in headless mode (no display connected therefore the H3's display engine disabled): http://linux-sunxi.org/User_talk ... rals_and_4.5V_DC-IN

Then I used RPi-Monitor to determine the lower cpufreq clockspeed limit:



Since it makes nearly no difference whether the SoC is idle at 240/480/720 MHz I ended up with these settings now:

1. echo interactive >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
   
2. echo 720000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
   
3. echo 1200000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Copy code

With these settings the OPi PC idles most of the times at 720MHz/940mV and increases cpufreq immediately if needed to 1200MHz/1180mV. This does not only avoid the well known heat problems (I'm not able to exceed 55°C under full load at 23°C ambient temperature) it saves also a lot of energy and prevents your SoC being fryed due to the insane default dvfs settings (idling at 1.3V or even 1.5V when performance governor is used). And the system is exactly as fast at 1.2GHz/interactive compared to the overvolted defaults.
The aforementioned dvfs settings are not safe for 'normal useage' with connected display. In this case voltages have to be increased a little. Compare with this thread to get the idea what's to be done to fix the thermal issues.

hojnikb

Is it possible to go lower with the voltage ?
Something like 800mV for 240Mhz.

I'm sure just lowering frequency doesn't help much with heat if voltage stays the same.