please choosego to mobile | Continue to access the PC version
View: 67930|Reply: 52

RPi-Monitor for H3

[Copy link]
Published in 2015-11-21 22:55:24 | Show all floors |Read mode
Edited by bronco at 2015-12-23 23:09

UPDATE: A newer version that is easier to install can be found in this thread (the following might be worth a read though)

Hi,

I'm still waiting for 2 Orange Pi PC to arrive but prepared already a template for RPi-Monitor to get a clue what's going on. The get an idea what RPi-Monitor can do for you have a look at this A20 adoption (works on Orange Pi and Orange Pi Mini): http://forum.armbian.com/index.p ... ts-for-rpi-monitor/

With the H3 there's no need to run temperature daemons so it's just template stuff. Here's a draft template for H3 suitable to record and display the following:
  1. #  Information               Status     Statistics
  2. #  - cpu frequency           - yes      - yes
  3. #  - cpu load 1, 5, 15       - yes      - yes
  4. #  - cpu scaling governor    - yes      - no
  5. #  - cpus available          - yes      - yes
  6. #  - dram frequency          - yes      - yes
  7. #  - zone0 temperature       - yes      - yes
  8. #  - zone1 temperature       - yes      - yes
Copy code


Installation (for experienced users!) is easy and takes just a couple of minutes:

1) Follow the simple instructions to install RPi-Monitor

2) Stop rpimonitor: "systemctl stop rpimonitor" ("service stop rpimonitor" prior to Jessie)

3) Save the draft template as /etc/rpimonitor/template/Allwinner_H3.conf

4) Create /etc/rpimonitor/template/OrangePi_H3.conf with the following contents
  1. web.page.icon='img/logo.png'
  2. web.page.menutitle='OPi-Monitor  <sub>('+data.hostname+')</sub>'
  3. web.page.pagetitle='OPi-Monitor ('+data.hostname+')'

  4. web.status.1.name=Orange Pi
  5. web.statistics.1.name=Orange Pi

  6. include=/etc/rpimonitor/template/version.conf
  7. include=/etc/rpimonitor/template/uptime.conf
  8. include=/etc/rpimonitor/template/Allwinner_H3.conf
  9. include=/etc/rpimonitor/template/memory.conf
  10. #include=/etc/rpimonitor/template/swap.conf
  11. include=/etc/rpimonitor/template/sdcard.conf
  12. include=/etc/rpimonitor/template/network.conf
Copy code
5) Relink data.conf:
  1. ln -sf /etc/rpimonitor/template/OrangePi_H3.conf /etc/rpimonitor/data.conf
Copy code
6) Start rpimonitor: "systemctl start rpimonitor" ("service start rpimonitor" prior to Jessie)

You can then connect with any modern browser to port 8888 of your OPi (cookies needed).

Caveats: I have no idea whether the template I hacked together works, which data sources thermal_zone0 and thermal_zone1 use and also no idea whether the check for active CPU cores works. Therefore this is currently something for more experienced users willing to fix stuff on their own.

EDIT: Template works, thermal values do now work, check for active CPU cores also works. Simply try it out using "echo 0 >/sys/devices/system/cpu/cpu3/online" (1 to re-enable).

In case you use Arch Linux a different RegEx to read-out available Memory is needed -- see below. Feedback regarding the template welcome.





9

threads

634

posts

4398

credits

Moderator

Rank: 7Rank: 7Rank: 7

credits
4398
Published in 2015-12-23 23:09:35 | Show all floors
I don't really understand why OPi PC is announced as 1,6GHz capable device.


Numbers sell.

5

threads

354

posts

2614

credits

Moderator

Rank: 7Rank: 7Rank: 7

credits
2614
Published in 2015-11-22 07:12:34 | Show all floors
This is how it looks with your configuration (unchanged):


PS. Your posting style reminds me a certain "emperor".

This thread contains more resources

You need to Log in to download or view,No account?    Register

x
Boards:
orangepi plus, olinuxino A20, cubieboard A10, mele A2000 .....
 Author| Published in 2015-11-22 15:42:58 | Show all floors
fritz replied at 2015-11-22 07:12
This is how it looks with your configuration (unchanged):

Thanks for the feedback. The first thing that's strange is the temperature readout. What do you get when you do a
  1. cat /sys/devices/virtual/thermal/thermal_zone0/temp
Copy code
On every platform these thermal values have to be divided by 1000 to get degree Celsius. Seems like this is patched somewhat and outputs already the divided value? In case you get degree celsius then the postprocessing filter has to be changed from "sprintf("%.1f", $1/1000)" to "" instead.

Then memory stats aren't working (this is Xavier's original stuff I never touched in /etc/rpimonitor/template/memory.conf) and since loboris' images doesn't seem to define swap you might comment out the "include=/etc/rpimonitor/template/swap.conf" in OrangePi_H3.conf and also adjust /etc/rpimonitor/template/sdcard.conf and comment out the /boot section.

Apart from that it seems it's working. After adjusting the temperature readouts it should be ready to tweak clock speeds (the far more interesting stuff doesn't happen on the status page but on statistics -- this is where you easily see how adjustments work when correcting clockspeeds of DRAM and CPU cores).

5

threads

354

posts

2614

credits

Moderator

Rank: 7Rank: 7Rank: 7

credits
2614
Published in 2015-11-22 20:23:38 | Show all floors
  1. [fritz@alarm-OTT ~]$ cat /sys/devices/virtual/thermal/thermal_zone0/temp
  2. 45
  3. [fritz@alarm-OTT ~]$ cat /proc/meminfo
  4. MemTotal:        1026872 kB
  5. MemFree:          917080 kB
  6. Buffers:           14632 kB
  7. Cached:            54220 kB
  8. SwapCached:            0 kB
  9. Active:            27520 kB
  10. Inactive:          50132 kB
  11. Active(anon):       9040 kB
  12. Inactive(anon):      148 kB
  13. Active(file):      18480 kB
  14. Inactive(file):    49984 kB
  15. Unevictable:           0 kB
  16. Mlocked:               0 kB
  17. HighTotal:        270336 kB
  18. HighFree:         208864 kB
  19. LowTotal:         756536 kB
  20. LowFree:          708216 kB
  21. SwapTotal:             0 kB
  22. SwapFree:              0 kB
  23. Dirty:                 0 kB
  24. Writeback:             0 kB
  25. AnonPages:          8824 kB
  26. Mapped:            10972 kB
  27. Shmem:               380 kB
  28. Slab:              11748 kB
  29. SReclaimable:       5060 kB
  30. SUnreclaim:         6688 kB
  31. KernelStack:         656 kB
  32. PageTables:          384 kB
  33. NFS_Unstable:          0 kB
  34. Bounce:                0 kB
  35. WritebackTmp:          0 kB
  36. CommitLimit:      513436 kB
  37. Committed_AS:      29000 kB
  38. VmallocTotal:     245760 kB
  39. VmallocUsed:       16720 kB
  40. VmallocChunk:     212864 kB
Copy code

I have now commented out the postprocessing filter for the thermal values.
memory stats does not work while there is no "MemAvailable" in /proc/meminfo
in memory.conf:
  1. web.status.1.content.5.line.1="Used: <b>" + KMG(data.memory_total-data.memory_available,'M')............
Copy code


Boards:
orangepi plus, olinuxino A20, cubieboard A10, mele A2000 .....
 Author| Published in 2015-11-22 21:13:56 | Show all floors
Edited by bronco at 2015-11-23 03:16
fritz replied at 2015-11-22 20:23
I have now commented out the postprocessing filter for the thermal values.
memory stats does not wo ...

Thx for the confirmation regarding thermal values. I already had a look through loboris' kernel sources and by looking into it I felt like the reporting is different due to thermal throttling values being specified "wrong" (already divided by 1000 in script.bin). Anyway, I corrected the template and exchanged the link in the original posting.
Regarding the memory stats: What's not working is to get "memory_available". Xavier tries to parse the output of "/usr/bin/free -mk" and Arch Linux requires another RegEx (I knew why I posted this into the Debian subforum ): https://github.com/XavierBerger/RPi-Monitor/issues/89


After the corrections made and rpimonitord being restarted it would be great if you could install the 'stress' tool and then execute the following:
  1. #!/bin/bash
  2. sleep 60
  3. echo 0 >/sys/devices/system/cpu/cpu3/online
  4. echo 0 >/sys/devices/system/cpu/cpu2/online
  5. sleep 60
  6. echo 480000 >/sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/cur_freq
  7. sleep 60
  8. echo 1 >/sys/devices/system/cpu/cpu3/online
  9. echo 1 >/sys/devices/system/cpu/cpu2/online
  10. sleep 60
  11. echo 1008000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
  12. sleep 60
  13. echo 480000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
  14. sleep 60
  15. echo 1536000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
  16. echo 672000 >/sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/cur_freq
Copy code
And then directly a second time while in another shell there's running "stress -c 4 -m 2 -i 2" and then provide the "Load / Clockspeeds / Temperature" graph from the statistics page. Really curious how temperatures (consumption) differ.

5

threads

354

posts

2614

credits

Moderator

Rank: 7Rank: 7Rank: 7

credits
2614
Published in 2015-11-26 05:48:24 | Show all floors
After some changes on Archlinuxarm now it looks like this:


@bronco
Your script has some errors, you can not write to /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/cur_freq this is only for reading.
Fixed script:
  1. #!/bin/bash
  2. sleep 60
  3. echo 0 > /sys/devices/system/cpu/cpu3/online
  4. echo 0 > /sys/devices/system/cpu/cpu2/online
  5. sleep 60
  6. echo 480000 > /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/userspace/set_freq
  7. sleep 60
  8. echo 1 > /sys/devices/system/cpu/cpu3/online
  9. echo 1 > /sys/devices/system/cpu/cpu2/online
  10. sleep 60
  11. echo 1008000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
  12. sleep 60
  13. echo 480000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
  14. sleep 60
  15. echo 1536000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
  16. echo 672000 > /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/userspace/set_freq
Copy code

Well I have repeated 2 times the first test (only script) while I started with 576 Mhz DRAM freq. and then at the end combined with "stress"
screenshot:


I should mention this test was made on a "non-orange" H3 device without cooler.

This thread contains more resources

You need to Log in to download or view,No account?    Register

x
Boards:
orangepi plus, olinuxino A20, cubieboard A10, mele A2000 .....
 Author| Published in 2015-11-26 07:15:54 | Show all floors
fritz replied at 2015-11-26 05:48
After some changes on Archlinuxarm now it looks like this:

Thx, I'll give it a try myself when my OPi PC arrive.

It's close to unbelievable that noone here get's the idea what's going wrong with the settings you drive your H3 devices:
When idle, it's about 40 - 45 degrees. So nothing to worry about
With heatsink and fan. When being totally idle. And we're not talking about Pentium IV or other broken stuff but an energy efficient A7 design from Allwinner. The good news: https://olimex.wordpress.com/201 ... test/#comment-20631

It's insane but people seem to like the impression that they've superiour hardware (not true at all with H3) that needs special treatment to run reliable (not true at all with H3). This is an overclocker's forum. Crazy sh*t.


 Author| Published in 2015-11-26 16:05:08 | Show all floors
Edited by bronco at 2015-11-26 19:08

Final update: http://pastebin.com/dQYTE5BH

But I still doubt that any of the overclocking/overvolting fanatics here gets the idea what's wrong
Did nobody realise that Xunlong shipped the devices with moronic overclocking/overvolting settings (look at your own graph above)? Settings that can be easily replaced with something sane?
  1. boot_clock      = 1008
  2. dram_clk        = 672

  3. [dvfs_table]
  4. pmuic_type = 2
  5. extremity_freq  = 1536000000
  6. max_freq        = 1200000000
  7. min_freq        = 108000000
  8. LV_count        = 8
  9. LV1_freq        = 1200000000
  10. LV1_volt        = 1320
  11. LV2_freq        = 1104000000
  12. LV2_volt        = 1250
  13. LV3_freq        = 1008000000
  14. LV3_volt        = 1200
  15. LV4_freq        = 960000000
  16. LV4_volt        = 1160
  17. LV5_freq        = 816000000
  18. LV5_volt        = 1100
  19. LV6_freq        = 540000000
  20. LV6_volt        = 1040
  21. LV7_freq        = 300000000
  22. LV7_volt        = 960
  23. LV8_freq        = 108000000
  24. LV8_volt        = 960
Copy code



4

threads

52

posts

284

credits

Intermediate member

Rank: 3Rank: 3

credits
284
Published in 2015-11-26 16:37:22 | Show all floors
bronco replied at 2015-11-26 07:15
Thx, I'll give it a try myself when my OPi PC arrive.

It's close to unbelievable that noone here  ...

My OPI + runs for 3 - 4 months flawlessly a webserver, ftp server, media server, transmission, samba and owncloud and does it much faster than my previous A20 based board. And that for a price that is almost unbelievable.

According to the specification sheet of the H3 it may even be used in environments with temperatures up to 70 degrees, so (to be honest): I really don't give a (%*&#^$%&@! that it is around 40 degrees when idle and somewhere in the 70's under full load. If it burns out I simply buy a new one.  On top of this the H3 has overheating protection, so it slows down if it becomes too hot. Unless your application(s) consume 100% cpu time it might be an issue, but I hardly believe this is true.





 Author| Published in 2015-11-26 17:05:10 | Show all floors
makama80 replied at 2015-11-26 16:37
My OPI + runs for 3 - 4 months flawlessly a webserver, ftp server, media server, transmission, samb ...

If it runs faster than the A20 board then something went wrong with settings/configuration. But that doesn't matter (and you won't believe it anyway)

What matters is this for example http://www.orangepi.org/orangepi ... =6581&fromuid=29411 and the many other stability complaints the forum here is full of.

When Xunlong switched to the H3 (they wanted the A31s instead) they had a problem: Single threaded performance (that's the most important one on a desktop system) worse than A20. What to do? Hey, let's overclock a 1.2 GHz SoC to 1.6 GHz. What's needed? Insane overvolting. Does it matter? Not for the manufacturer since warranty handling doesn't exist between Shenzen and the rest of the world. It does matter for customers because these insane overvolting/overclocking dvfs entries Steven set in the first OS images are the reason why you fry your devices, why you all suffer from heat problems and need heatsinks and fans and why you all experience stability problems the moment you really need the performance the settings were made for.

It's just moronic to fry a device @ 1.3V when it's idle. But it's obviously useless to discuss this stuff. Now i know that the problem with the H3 isn't hardware related but originates from marketing lies and insane settings that can be fixed easily. But noone in this overclocker community wants to try it out. You all seem to be confident that it's necessary to heat up a device with insane overvolting settings even if it's doing nothing (and 'doing nothing' is the state a SBC is in most of the times). Happy frying!
You need to log in before you can reply login | Register

Points Rule

Quick reply Top Return list