Jump to content

Recommended Posts

Posted
  On 7/14/2018 at 6:08 PM, TonyMac32 said:

 

I see that on Amazon.de, but not amazon.com for us colonists...:P

top and bottom have no holes, but that certainly looks sharp.  Add it to the "Pi-factor cases" topic?

Expand  

Raidsonic.de is a company in Germany, which sells the brand "ICY BOX" : https://www.raidsonic.de/en/index.php

(the ebay-seller where I did buy will send it worldwide:  eBay item number 362279671071 - free postage)


Yes- top and bottom doesnt got holes, but at the longer sides there is grid-aluminium for "fresh air".
Also the bottom plate could absorb/spread the heat.

I know some time ago I did see the case-thread, but I didnt find it now while searching for some keywords :(
[EDIT]
here is the thread

 

Posted

while waiting for the final (stable?) version of armbian with kernel 4.18 I did go back to armbian stable: for better hw-support

ARMBIAN 5.47 stable Debian GNU/Linux 9 (stretch) 4.14.51-sunxi64

Linux npi-k1-plus 4.14.51-sunxi64 #23 SMP Sun Jun 24 12:19:01 UTC 2018 aarch64 GNU/Linux

 

here I did miss the temperature in armbianmonitor -m  :(

So I did take a look at my Neo2 and found the missing link :)
 

cd  /etc/armbianmonitor/datasources/
ln -s /sys/devices/virtual/thermal/thermal_zone0/temp soctemp

After creating the symbolic link I do get also the temperature from armbianmonitor:

root@npi-k1-plus(192.168.6.70):/etc/armbianmonitor/datasources# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

16:26:42:  648MHz  0.00   0%   0%   0%   0%   0%   0% 36.9°C  0/8
16:26:47:  408MHz  0.00   0%   0%   0%   0%   0%   0% 37.0°C  0/8
16:26:53:  408MHz  0.00   0%   0%   0%   0%   0%   0% 36.9°C  0/8
16:26:58:  408MHz  0.00   0%   0%   0%   0%   0%   0% 36.9°C  0/8
16:27:03:  408MHz  0.00   1%   0%   0%   0%   0%   0% 37.3°C  0/8
16:27:08:  408MHz  0.00   0%   0%   0%   0%   0%   0% 36.5°C  0/8

root@npi-k1-plus(192.168.6.70):/# cat /sys/devices/virtual/thermal/thermal_zone0/temp|awk '{printf "%.2f\n", ($1/1000)}'
37.39

after getting the temperature in armbianmonitor we also have the temperature in the welcome screen :)
 

Welcome to ARMBIAN 5.47 stable Debian GNU/Linux 9 (stretch) 4.14.51-sunxi64
System load:   0.00 0.00 0.00   Up time:       3:15 hours               Local users:   2
Memory usage:  3 % of 2002MB    IP:            192.168.6.70
CPU temp:      37°C
Usage of /:    4% of 30G

PS: /sys/devices/virtual/thermal/thermal_zone0/temp is missing in the dev-image so there no temperature 

Posted
  On 7/15/2018 at 1:30 PM, guidol said:

So I did take a look at my Neo2 and found the missing link

Expand  

 

This is something that should happen automagically at boot. Can you please provide output from

grep soctemp /etc/init.d/armhwinfo

 

Posted
  On 7/15/2018 at 1:49 PM, tkaiser said:

 

This is something that should happen automagically at boot. Can you please provide output from

grep soctemp /etc/init.d/armhwinfo

Expand  
root@npi-k1-plus(192.168.6.70):/# grep soctemp /etc/init.d/armhwinfo
grep: /etc/init.d/armhwinfo: Datei oder Verzeichnis nicht gefunden

 

Posted
  On 7/15/2018 at 2:30 PM, tkaiser said:

Then your image already uses /usr/lib/armbian/armbian-hardware-monitor and there the symlink should be created automatically at boot. Strange.

Expand  

root@npi-k1-plus(192.168.6.70):/etc/init.d# grep soctemp /usr/lib/armbian/armbian-hardware-monitor
                ln -fs /sys/devices/platform/a20-tp-hwmon/temp1_input /etc/armbianmonitor/datasources/soctemp
                ln -fs /sys/class/hwmon/hwmon0/temp1_input /etc/armbianmonitor/datasources/soctemp
                ln -fs /sys/devices/virtual/thermal/${THERMAL_ZONE}/temp /etc/armbianmonitor/datasources/soctemp
        # remove the soctemp node on platforms where kernel support is not yet ready for thermal readouts
        cat /etc/armbianmonitor/datasources/soctemp >/dev/null 2>&1 || rm /etc/armbianmonitor/datasources/soctemp
root@npi-k1-plus(192.168.6.70):/etc/init.d# echo ${THERMAL_ZONE}

root@npi-k1-plus(192.168.6.70):/etc/init.d#
 

Should ${THERMAL_ZONE} be set outside the script?

( as /sys/devices/virtual/thermal/thermal_zone0/temp = thermal_zone0 )

 

${BOARDFAMILY} seems to be available

root@npi-k1-plus(192.168.6.70):/etc/init.d# echo ${BOARDFAMILY}
sun50iw2
 

So when ${THERMAL_ZONE} is empty it looks like the symbolic link is removed:

else
		# all other boards/kernels use the same sysfs node except of Actions Semi S500:
		[[ ${BOARDFAMILY} == s500 ]] && THERMAL_ZONE="thermal_zone1" || THERMAL_ZONE="thermal_zone0"
		ln -fs /sys/devices/virtual/thermal/${THERMAL_ZONE}/temp /etc/armbianmonitor/datasources/soctemp
	fi
	# remove the soctemp node on platforms where kernel support is not yet ready for thermal readouts
	cat /etc/armbianmonitor/datasources/soctemp >/dev/null 2>&1 || rm /etc/armbianmonitor/datasources/soctemp

Is sun50iw2 = s500 BoardFamily? because sun50iw2 isnt in the script....

Posted
  On 7/15/2018 at 2:39 PM, guidol said:

Should ${THERMAL_ZONE} be set outside the script?

Expand  

 

No. How does the output of the following look like?

/bin/bash -x /usr/lib/armbian/armbian-hardware-monitor start

 

Posted
  On 7/15/2018 at 5:01 PM, tkaiser said:

 

No. How does the output of the following look like?

/bin/bash -x /usr/lib/armbian/armbian-hardware-monitor start

 

Expand  

here it is in the hidden box:
 

  Reveal hidden contents

 

Posted
  On 7/15/2018 at 5:07 PM, guidol said:

here it is in the hidden box

Expand  

 

The script uses /sys/class/hwmon/hwmon0/temp1_input since this should be the 'usual place' with modern kernels. Is reading out the temperature working now or not ('cat /etc/armbianmonitor/datasources/soctemp')

Posted
  On 7/15/2018 at 5:25 PM, tkaiser said:

The script uses /sys/class/hwmon/hwmon0/temp1_input since this should be the 'usual place' with modern kernels. Is reading out the temperature working now or not ('cat /etc/armbianmonitor/datasources/soctemp')

Expand  

Now - after the script - it does use another symbolic link (as written by you above) :
root@npi-k1-plus(192.168.6.70):/# cat /etc/armbianmonitor/datasources/soctemp
36905
root@npi-k1-plus(192.168.6.70):/# ls -l /etc/armbianmonitor/datasources/soctemp
lrwxrwxrwx 1 root root 35 Jul 15 20:08 /etc/armbianmonitor/datasources/soctemp -> /sys/class/hwmon/hwmon0/temp1_input

 

I used before
root@npi-k1-plus(192.168.6.70):/# cat /sys/devices/virtual/thermal/thermal_zone0/temp
36542
 

Posted
  On 7/15/2018 at 6:05 PM, guidol said:

root@npi-k1-plus(192.168.6.70):/# ls -l /etc/armbianmonitor/datasources/soctemp
lrwxrwxrwx 1 root root 35 Jul 15 20:08 /etc/armbianmonitor/datasources/soctemp -> /sys/class/hwmon/hwmon0/temp1_input

Expand  

 

This is as expected on most recent Armbian images with mainline kernel. I still don't get it: is there a problem or not? It should be set this way after each and every reboot as long as thermal support is available in the specific kernel branch.

Posted
  On 7/15/2018 at 6:21 PM, tkaiser said:

This is as expected on most recent Armbian images with mainline kernel. I still don't get it: is there a problem or not? It should be set this way after each and every reboot as long as thermal support is available in the specific kernel branch.

Expand  

I did a reboot and the symbolic link is gone :(

 

So I have to do 

ln -s /sys/class/hwmon/hwmon0/temp1_input /etc/armbianmonitor/datasources/soctemp    (prefered by the new system!?)

or

ln -s /sys/devices/virtual/thermal/thermal_zone0/temp /etc/armbianmonitor/datasources/soctemp

 

Kernel 4.14.51-sunxi64 seems - for me - to have thermal support available, but on this version it doesnt seems to be recognized by the script :(
(or the script doesnt run at startup - how could I check this?)

Posted
  On 7/15/2018 at 6:55 PM, tkaiser said:
systemctl status armbian-hardware-monitor

 

Expand  

Hmm - looks like it started, but without setting the link manually (or via /etc/rc.local) I didnt get a temperature readout:
 

root@npi-k1-plus(192.168.6.70):~# systemctl status armbian-hardware-monitor
● armbian-hardware-monitor.service - Armbian hardware monitoring
   Loaded: loaded (/lib/systemd/system/armbian-hardware-monitor.service; enabled; vendor preset: enabled)
   Active: active (exited) since Sun 2018-07-15 21:59:13 +03; 1min 4s ago
  Process: 594 ExecStart=/usr/lib/armbian/armbian-hardware-monitor start (code=exited, status=0/SUCCESS)
 Main PID: 594 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/armbian-hardware-monitor.service

Jul 15 21:59:10 npi-k1-plus systemd[1]: Starting Armbian hardware monitoring...
Jul 15 21:59:13 npi-k1-plus systemd[1]: Started Armbian hardware monitoring.

BUT if I stop/start armbian-hardware-monitor the temperature-readout does WORK :)  without setting the link manually- so it seems to be like a timeout or not ready service:
 

root@npi-k1-plus(192.168.6.70):~# systemctl stop armbian-hardware-monitor
root@npi-k1-plus(192.168.6.70):~# systemctl start armbian-hardware-monitor
root@npi-k1-plus(192.168.6.70):~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

22:05:38:  648MHz  0.29  10%   3%   4%   0%   1%   0% 38.1°C  0/8
22:05:43:  408MHz  0.26   0%   0%   0%   0%   0%   0% 37.5°C  0/8

 

Posted

Weird. You could add the following just below the '#!/bin/bash' line and then post the contents of /tmp/armbian-hardware-monitor-debug.txt after a reboot, then waiting 5 minutes and then stopping/starting the service again:

exec 2>>/tmp/armbian-hardware-monitor-debug.txt
set -x
date

 

Posted
  On 7/15/2018 at 7:39 PM, tkaiser said:

Weird. You could add the following just below the '#!/bin/bash' line and then post the contents of /tmp/armbian-hardware-monitor-debug.txt after a reboot, then waiting 5 minutes and then stopping/starting the service again:

exec 2>>/tmp/armbian-hardware-monitor-debug.txt
set -x
date

 

Expand  

I added this to /usr/lib/armbian/armbian-hardware-monitor.

After reboot:
 

  Reveal hidden contents

 

5 Minutes later and 

systemctl stop armbian-hardware-monitor

systemctl start armbian-hardware-monitor

  Reveal hidden contents

 

My follwing little bash-script (out of the monitor-script) does work:
 

#!/bin/bash
# SoC temp:
if [[ -f /sys/class/hwmon/hwmon0/temp1_input ]]; then
   # usual convention with modern kernels
   echo 'setze Link'
   ln -fs /sys/class/hwmon/hwmon0/temp1_input /etc/armbianmonitor/datasources/soctemp
fi

Thats the same source-code....

Posted
  On 7/15/2018 at 7:53 PM, guidol said:

+ ln -fs /sys/class/hwmon/hwmon0/temp1_input /etc/armbianmonitor/datasources/soctemp
+ cat /etc/armbianmonitor/datasources/soctemp
+ rm /etc/armbianmonitor/datasources/soctemp

Expand  

 

That's the culprit. The sysfs node is present at boot but can not be read out for whatever reasons. So it's some sort of a timing problem. I added removal of the /etc/armbianmonitor/datasources/soctemp symlink to get 'nicer' output with 'armbianmonitor -m' some time ago but seems like this is counterproductive. Can you try to repeat the test after commenting this line

Posted
  On 7/15/2018 at 8:09 PM, tkaiser said:

Can you try to repeat the test after commenting this line

Expand  

Directly after the reboot (with commented rm) the link is there :) and temperature-readout does work out of the box!
 

  Reveal hidden contents

 

5 Minutes later and 

systemctl stop armbian-hardware-monitor

systemctl start armbian-hardware-monitor

  Reveal hidden contents

 

Posted
  On 7/15/2018 at 8:24 PM, guidol said:

Directly after the reboot (with commented rm) the link is there :) and temperature-readout does work out of the box!

Expand  

 

I deleted removal of the symlink now: https://github.com/armbian/build/commit/52bef7ddf9d424eb65d831385714a9da66153078 (hopefully more people will test and report back, especiall wrt ondemand scheduler behaviour -- always remaining at max cpufreq with recent kernels)

Posted

Happy to report both SPI channels worked properly with 5.47 stable using 4.14.51-sunxi64:

 

 

_7160703.JPG

Posted
  On 7/15/2018 at 9:13 PM, tkaiser said:

especiall wrt ondemand scheduler behaviour -- always remaining at max cpufreq with recent kernels)

Expand  

because of that I use the conservative governer as current governer.

Posted
  On 7/16/2018 at 6:08 AM, guidol said:

because of that I use the conservative governer as current governer

Expand  

 

I read about that 'workaround' but this one is no option as already explained in detail (since not behaving correctly with I/O loads -- switching to conservative trashes storage performance). It would be better if users would help testing instead of promoting broken workarounds.

Posted
  On 7/16/2018 at 6:14 AM, tkaiser said:

It would be better if users would help testing instead of promoting broken workarounds.

Expand  

How could I help testing the broken ondemand?
I did see on several SBCs that ondemand isnt working and switched to conservative?

I didnt promote conservative - I only want the CPU to switch down - a thing that ondemand at this time doesnt do.

Posted
  On 7/16/2018 at 8:18 AM, guidol said:

How could I help testing the broken ondemand?

Expand  

 

By testing with second part of the aforementioned commit.

 

As @BRSS discovered the sampling_rate value changed with some kernel version and that affects the governor's behaviour: https://forum.armbian.com/topic/6398-orange-pi-zero-cpu-and-load-issues-with-538/?tab=comments#comment-58057 (let's ignore the 'average load' problem for now since unrelated).

 

So by testing through different values and this also with some older kernels we could try to come up again with settings that match everywhere. 'Legacy'/default kernels aren't that much of an issue since we use with sunxi kernels lower than 4.x the interactive governor (since ondemand sucks with Allwinner BSP kernels and interactive is the only reasonable choice).

 

So it's really just testing through higher sampling_rate values with some kernel variants. Discussion should IMO better happen in the other thread (even if 'wrong' subforum).

 

 

 

Posted
  On 7/16/2018 at 9:01 AM, tkaiser said:

So by testing through different values and this also with some older kernels we could try to come up again with settings that match everywhere. 'Legacy'/default kernels aren't that much of an issue since we use with sunxi kernels lower than 4.x the interactive governor (since ondemand sucks with Allwinner BSP kernels and interactive is the only reasonable choice).

Expand  

 

for testing I switched the K1 Plus back to ondemand and did take a look at 
root@npi-k1-plus(192.168.6.70):~# more /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
10000
 

With 10000 ondemand doenst switch down with kernel  4.14.51-sunxi64, but when setting the rate to 20000
echo 20000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate

 

ondemand as governer does beginn to switch down the frequency:
 

root@npi-k1-plus(192.168.6.70):~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

15:23:30: 1152MHz  0.06   0%   0%   0%   0%   0%   0% 37.5°C  0/8
15:23:35: 1152MHz  0.05   0%   0%   0%   0%   0%   0% 37.4°C  0/8
15:23:41: 1152MHz  0.05   0%   0%   0%   0%   0%   0% 37.6°C  0/8
15:23:46: 1152MHz  0.04   0%   0%   0%   0%   0%   0% 37.3°C  0/8
15:23:51:  648MHz  0.04   0%   0%   0%   0%   0%   0% 37.5°C  0/8
15:23:56:  408MHz  0.04   0%   0%   0%   0%   0%   0% 37.6°C  0/8
15:24:01: 1152MHz  0.03   0%   0%   0%   0%   0%   0% 37.5°C  0/8
15:24:06:  408MHz  0.03   0%   0%   0%   0%   0%   0% 37.6°C  0/8
15:24:11:  408MHz  0.03   0%   0%   0%   0%   0%   0% 37.9°C  0/8
15:24:16:  408MHz  0.03   0%   0%   0%   0%   0%   0% 38.1°C  0/8

15:46:52:  408MHz  0.00   0%   0%   0%   0%   0%   0% 37.1°C  0/8
15:46:57: 1152MHz  0.00   0%   0%   0%   0%   0%   0% 37.0°C  0/8
15:47:02:  408MHz  0.00   0%   0%   0%   0%   0%   0% 37.3°C  0/8
15:47:07:  408MHz  0.00   0%   0%   0%   0%   0%   0% 37.1°C  0/8
15:47:12:  408MHz  0.00   0%   0%   0%   0%   0%   0% 36.7°C  0/8
15:47:17:  408MHz  0.00   0%   0%   0%   0%   0%   0% 36.8°C  0/8
15:47:22: 1152MHz  0.00   0%   0%   0%   0%   0%   0% 37.0°C  0/8
15:47:27:  408MHz  0.00   0%   0%   0%   0%   0%   0% 37.3°C  0/8
15:47:32:  408MHz  0.00   0%   0%   0%   0%   0%   0% 36.9°C  0/8

with one little peak to 1152Mhz (maybe a write to sd?)

 

@tkaiser In the thread 'Orange Pi Zero - CPU and Load issues with 5.38" you did wrote about a value of 200000

  Quote

Simply edit /etc/init.d/armhwinfo and search for 'ondemand' there, then add the missing 'echo 200000 >${i}/sampling_rate' line, play around with the values and report back.

Expand  

 Isnt 200000 to high - or is that a value for a Orange Pi Zero?

Posted
  On 7/16/2018 at 1:21 PM, tkaiser said:

I tested around with next branch on NanoPi Fire3, Clearfog Pro and RK3328. With those kernel settings 20,000 is way too low.

Expand  

2.4 Ondemand

sampling_rate:

Measured in uS (10^-6 seconds), this is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more.

 

So how much CPU usage we do get more when we use 200.000 against 20.000?
The K1 Plus will also switch with 200.000 as samplingrate.

Do we need a higher samplingrate with a faster CPU like on the NanoPi Fire3, Clearfog Pro and RK3328? (because Fire3 is a OctaCore)

Posted

Strange :(
I edited the /usr/lib/armbian/armbian-hardware-optimization ondemand-part for the samplingrate like
 

        # tweak ondemand cpufreq governor settings to increase cpufreq with IO load
        grep -q ondemand /etc/default/cpufrequtils
        if [ $? -eq 0 ]; then
                echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
                cd /sys/devices/system/cpu
                for i in cpufreq/ondemand cpu0/cpufreq/ondemand cpu4/cpufreq/ondemand ; do
                        if [ -d $i ]; then
                                echo 1 >${i}/io_is_busy
                                echo 25 >${i}/up_threshold
                                echo 10 >${i}/sampling_down_factor
                                echo 20000 >${i}/sampling_rate
                        fi
                done
        fi

but after reboot I only get as value 10000:
root@npi-k1-plus(192.168.6.70):~# more /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
10000
 

So the governor doesnt switch :(
But when I insert
echo 20000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate

at the end of /etc/rc.local (before exit 0)

then the governor does switch down to 408Mhz

Posted
  On 7/16/2018 at 1:34 PM, guidol said:

Measured in uS (10^-6 seconds), this is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more.

Expand  

 

With 10,000 the kernel takes a look 100 hundred times each second, when set to 200,000 it's just 5 times any more. And this is all off-topic here as already said (but same applies to the other thread that talks about OPi Zero)

 

As a first step I tried to consolidate timer frequency settings accross all kernels since what we have today is just chaos.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines