RPi-Monitor for H3

bronco · Published in 2015-11-21 22:55:24

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:

# Information Status Statistics
# - cpu frequency - yes - yes
# - cpu load 1, 5, 15 - yes - yes
# - cpu scaling governor - yes - no
# - cpus available - yes - yes
# - dram frequency - yes - yes
# - zone0 temperature - yes - yes
# - 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

web.page.icon='img/logo.png'
web.page.menutitle='OPi-Monitor <sub>('+data.hostname+')</sub>'
web.page.pagetitle='OPi-Monitor ('+data.hostname+')'
web.status.1.name=Orange Pi
web.statistics.1.name=Orange Pi
include=/etc/rpimonitor/template/version.conf
include=/etc/rpimonitor/template/uptime.conf
include=/etc/rpimonitor/template/Allwinner_H3.conf
include=/etc/rpimonitor/template/memory.conf
#include=/etc/rpimonitor/template/swap.conf
include=/etc/rpimonitor/template/sdcard.conf
include=/etc/rpimonitor/template/network.conf

Copy code

5) Relink data.conf:

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.

igorpec · Published in 2015-12-23 23:09:35

I don't really understand why OPi PC is announced as 1,6GHz capable device.

Numbers sell.

fritz · Published in 2015-11-22 07:12:34

This is how it looks with your configuration (unchanged):

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

bronco · Published in 2015-11-22 15:42:58

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

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).

fritz · Published in 2015-11-22 20:23:38

[fritz@alarm-OTT ~]$ cat /sys/devices/virtual/thermal/thermal_zone0/temp
45
[fritz@alarm-OTT ~]$ cat /proc/meminfo
MemTotal: 1026872 kB
MemFree: 917080 kB
Buffers: 14632 kB
Cached: 54220 kB
SwapCached: 0 kB
Active: 27520 kB
Inactive: 50132 kB
Active(anon): 9040 kB
Inactive(anon): 148 kB
Active(file): 18480 kB
Inactive(file): 49984 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 270336 kB
HighFree: 208864 kB
LowTotal: 756536 kB
LowFree: 708216 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 8824 kB
Mapped: 10972 kB
Shmem: 380 kB
Slab: 11748 kB
SReclaimable: 5060 kB
SUnreclaim: 6688 kB
KernelStack: 656 kB
PageTables: 384 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 513436 kB
Committed_AS: 29000 kB
VmallocTotal: 245760 kB
VmallocUsed: 16720 kB
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:

web.status.1.content.5.line.1="Used: <b>" + KMG(data.memory_total-data.memory_available,'M')............

Copy code

bronco · Published in 2015-11-22 21:13:56

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:

#!/bin/bash
sleep 60
echo 0 >/sys/devices/system/cpu/cpu3/online
echo 0 >/sys/devices/system/cpu/cpu2/online
sleep 60
echo 480000 >/sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/cur_freq
sleep 60
echo 1 >/sys/devices/system/cpu/cpu3/online
echo 1 >/sys/devices/system/cpu/cpu2/online
sleep 60
echo 1008000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
sleep 60
echo 480000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
sleep 60
echo 1536000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
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.

fritz · Published in 2015-11-26 05:48:24

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:

#!/bin/bash
sleep 60
echo 0 > /sys/devices/system/cpu/cpu3/online
echo 0 > /sys/devices/system/cpu/cpu2/online
sleep 60
echo 480000 > /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/userspace/set_freq
sleep 60
echo 1 > /sys/devices/system/cpu/cpu3/online
echo 1 > /sys/devices/system/cpu/cpu2/online
sleep 60
echo 1008000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
sleep 60
echo 480000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
sleep 60
echo 1536000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
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.

bronco · Published in 2015-11-26 07:15:54

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.

bronco · Published in 2015-11-26 16:05:08

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?

boot_clock = 1008
dram_clk = 672
[dvfs_table]
pmuic_type = 2
extremity_freq = 1536000000
max_freq = 1200000000
min_freq = 108000000
LV_count = 8
LV1_freq = 1200000000
LV1_volt = 1320
LV2_freq = 1104000000
LV2_volt = 1250
LV3_freq = 1008000000
LV3_volt = 1200
LV4_freq = 960000000
LV4_volt = 1160
LV5_freq = 816000000
LV5_volt = 1100
LV6_freq = 540000000
LV6_volt = 1040
LV7_freq = 300000000
LV7_volt = 960
LV8_freq = 108000000
LV8_volt = 960

Copy code

makama80 · Published in 2015-11-26 16:37:22

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.

bronco · Published in 2015-11-26 17:05:10

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!

RPi-Monitor for H3

This thread contains more resources

This thread contains more resources