Please select To the mobile version | Continue to access the desktop computer version

OrangePi

 Login            
 Register            
Search
Hot search: orangepi
Author: bronco

RPi-Monitor for H3

[Copy link]

1

Threads

116

Posts

656

Credits

Senior member

Rank: 4

Credits
656
Post time 2015-11-26 23:23:31 | Show all posts
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 ?
 Author| Post time 2015-11-26 23:31:59 | Show all posts
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:
  1. boot_clock = 1008

  2. [dvfs_table]
  3. pmuic_type = 2
  4. pmu_gpio0 = port:PL06<1><1><2><1>
  5. pmu_level0 = 11300
  6. pmu_level1 = 576
  7. ;extremity_freq = 1536000000
  8. max_freq = 1200000000
  9. min_freq = 480000000
  10. LV_count = 7
  11. LV1_freq = 1200000000
  12. LV1_volt = 1320
  13. LV2_freq = 1104000000
  14. LV2_volt = 1250
  15. LV3_freq = 1008000000
  16. LV3_volt = 1200
  17. LV4_freq = 960000000
  18. LV4_volt = 1160
  19. LV5_freq = 816000000
  20. LV5_volt = 1100
  21. LV6_freq = 540000000
  22. LV6_volt = 1040
  23. LV7_freq = 480000000
  24. LV7_volt = 1040
Copy the 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.
 Author| Post time 2015-11-27 03:23:53 | Show all posts
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:
  1. echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
  2. for i in 1200000 1200000 1104000 1008000 912000 720000 480000 ; do
  3.         echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
  4.         sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4
  5. done
  6. for i in 480000 720000 912000 1008000 1104000 1200000 1200000 ; do
  7.         echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
  8.         sleep 120
  9. done
Copy the Code
Results depending on clock speed:
  1. 480 MHz: 398.1 sec.
  2. 720 MHz: 264.3 sec.
  3. 912 MHz: 208.6 sec.
  4. 1008 MHz: 188.6 sec.
  5. 1104 MHz: 172.1 sec.
  6. 1200 MHz: 158.2 sec.
Copy the 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:


 Author| Post time 2015-11-27 05:18:52 | Show all posts
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:
  1. [   66.870649] [ddrfreq] DDR: 672000KHz->480000KHz start
  2. [   66.870664] [ddrfreq] current cpu is cpu1
  3. [   66.871859] [ddrfreq] elapsed: 1046us
  4. [   66.871876] [ddrfreq] DDR: 672000KHz->480000KHz ok!
Copy the 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.
 Author| Post time 2015-11-27 05:37:27 | Show all posts
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.

5

Threads

355

Posts

2102

Credits

Moderator

Rank: 7Rank: 7Rank: 7

Credits
2102
Post time 2015-11-27 05:47:30 | Show all posts
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.
Boards:
orangepi plus, olinuxino A20, cubieboard A10, mele A2000 .....
 Author| Post time 2015-11-27 06:06:52 | Show all posts
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...
 Author| Post time 2015-11-27 06:40:47 | Show all posts
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
 Author| Post time 2015-11-27 08:14:47 | Show all posts
Edited by bronco at 2015-11-27 08:24

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

  1. extremity_freq = 1296000000
  2. max_freq = 1200000000
  3. min_freq = 480000000
  4. LV_count = 7
  5. LV1_freq = 1200000000
  6. LV1_volt = 1240
  7. LV2_freq = 1104000000
  8. LV2_volt = 1200
  9. LV3_freq = 1008000000
  10. LV3_volt = 1160
  11. LV4_freq = 960000000
  12. LV4_volt = 1100
  13. LV5_freq = 816000000
  14. LV5_volt = 1040
  15. LV6_freq = 540000000
  16. LV6_volt = 1000
  17. LV7_freq = 480000000
  18. LV7_volt = 960
Copy the 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:

  1. Testing CPU 0
  2. 1536 MHz SKIPPED
  3. 1440 MHz SKIPPED
  4. 1344 MHz SKIPPED
  5. 1200 MHz ............................................................ OK
  6. 1104 MHz ............................................................ OK
  7. 1008 MHz ............................................................ OK
  8.   912 MHz ............................................................ OK
  9.   816 MHz ............................................................ OK
  10.   720 MHz ............................................................ OK
  11.   648 MHz ............................................................ OK
  12.   600 MHz ............................................................ OK
  13.   504 MHz ............................................................ OK
  14.   480 MHz ............................................................ OK
  15.   408 MHz SKIPPED
  16.   312 MHz SKIPPED
  17.   240 MHz SKIPPED
  18.   120 MHz SKIPPED
  19.    60 MHz SKIPPED
Copy the Code


When my 2nd OPi PC arrrives I will automate these tests to get stable settings with as less voltage as possible...
 Author| Post time 2015-11-27 09:16:59 | Show all posts
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):

You have to log in before you can reply Login | Register

Points Rules

Archiver|Mobile edition|Darkroom|OrangePi En ( 粤ICP备14086627号-2

2019-11-13 15:43 GMT+8 , Processed in 0.039280 second(s), 20 queries .

Powered by Discuz! X3.2

© 2014-2015 orangepibbs en.

Quick Reply To Top Return to the list