BRSS Posted February 7, 2018 Posted February 7, 2018 Hi all, With a fresh install of version 5.38 (jessie 4.14.15, idle since 5 min.), I've a CPU throttling and load issues : Spoiler root@OPZ2:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 07:29:43: 1200MHz 1.11 23% 13% 8% 0% 1% 0% 44.5°C 0/8 07:29:48: 1200MHz 1.18 1% 0% 0% 0% 0% 0% 43.1°C 0/8 07:29:53: 1200MHz 1.15 0% 0% 0% 0% 0% 0% 43.0°C 0/8 07:29:58: 1200MHz 1.14 0% 0% 0% 0% 0% 0% 41.7°C 0/8 07:30:04: 1200MHz 1.13 0% 0% 0% 0% 0% 0% 41.6°C 0/8 07:30:09: 1200MHz 1.12 0% 0% 0% 0% 0% 0% 43.0°C 0/8 07:30:14: 1200MHz 1.11 1% 0% 0% 0% 0% 0% 41.7°C 0/8 ... 07:37:49: 1200MHz 1.00 1% 1% 0% 0% 0% 0% 39.3°C 0/8 07:37:54: 1200MHz 1.00 0% 0% 0% 0% 0% 0% 39.9°C 0/8 CPU frequency never drop under 1200MHz and CPU load never drop under 1.00. The same board and SD card with fresh install of version 5.35 : Spoiler root@OPZ2:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 07:59:51: 240MHz 0.04 1% 1% 0% 0% 0% 0% 39.1°C 0/8 07:59:57: 240MHz 0.04 1% 1% 0% 0% 0% 0% 39.6°C 0/8 08:00:02: 240MHz 0.20 1% 1% 0% 0% 0% 0% 40.2°C 0/8 08:00:07: 240MHz 0.17 1% 1% 0% 0% 0% 0% 39.2°C 0/8 08:00:13: 240MHz 0.15 1% 1% 0% 0% 0% 0% 39.3°C 0/8 08:00:18: 240MHz 0.14 1% 1% 0% 0% 0% 0% 39.9°C 0/8 08:00:23: 240MHz 0.13 1% 1% 0% 0% 0% 0% 40.3°C 0/8 08:00:29: 240MHz 0.12 1% 1% 0% 0% 0% 0% 39.8°C 0/8 08:00:34: 240MHz 0.11 1% 1% 0% 0% 0% 0% 39.9°C 0/8 08:00:39: 240MHz 0.10 1% 1% 0% 0% 0% 0% 39.2°C 0/8 08:00:45: 240MHz 0.09 1% 1% 0% 0% 0% 0% 39.7°C 0/8 08:00:50: 240MHz 0.08 1% 1% 0% 0% 0% 0% 39.6°C 0/8 08:00:56: 240MHz 0.08 1% 1% 0% 0% 0% 0% 39.4°C 0/8 08:01:01: 240MHz 0.07 1% 1% 0% 0% 0% 0% 39.4°C 0/8 08:01:06: 240MHz 0.06 1% 1% 0% 0% 0% 0% 40.1°C 0/8 CPU is most of the time @240MHz and load is way under 1.00. I've found a different value in /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate file : 10000 in v5.38 7044000 in v5.35. After applying the old value, CPU frequency drops when idle, but the load stay at 1.00 (cosmetic issue?) Spoiler root@OPZ2:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 08:08:40: 240MHz 1.00 1% 1% 0% 0% 0% 0% 39.9°C 0/8 08:08:45: 240MHz 1.00 1% 1% 0% 0% 0% 0% 39.2°C 0/8 08:08:51: 240MHz 1.00 1% 1% 0% 0% 0% 0% 39.4°C 0/8 08:08:56: 240MHz 1.00 1% 1% 0% 0% 0% 0% 39.6°C 0/8 08:09:01: 240MHz 1.00 1% 1% 0% 0% 0% 0% 39.6°C 0/8 08:09:07: 240MHz 1.00 1% 1% 0% 0% 0% 0% 38.8°C 0/8 08:09:12: 240MHz 1.00 1% 1% 0% 0% 0% 0% 39.2°C 0/8 08:09:17: 240MHz 1.00 1% 1% 0% 0% 0% 0% 39.1°C 0/8 08:09:23: 240MHz 1.00 1% 1% 0% 0% 0% 0% 38.8°C 0/8 08:09:28: 240MHz 1.07 1% 1% 0% 0% 0% 0% 39.3°C 0/8 Same issues when upgrading from 5.35 (or 5.37) to 5.38.
t-minik Posted February 8, 2018 Posted February 8, 2018 Hi. I had the exact same locked 1260mhz frequency on opi +2E and Pc+, both on Stretch 5.38 and 4.14.15 kernel. No problem with load for me. Thanks for the tip.
Moklev Posted February 8, 2018 Posted February 8, 2018 Same feedback. OPIZ v1.4 512MB (Debian Stretch 5.38) Linux orangepizero 4.14.15-sunxi #28 SMP Mon Jan 29 07:24:48 CET 2018 armv7l GNU/Linux Governor: ondemand Stuck at 1,2GHz without load (but load value is normal in my 5.38) Spoiler francesco@orangepizero:~$ sudo cpufreq-set -g ondemand francesco@orangepizero:~$ sudo armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 21:29:10: 1200MHz 0.09 6% 3% 3% 0% 0% 0% 54.2°C 0/8 21:29:15: 1200MHz 0.08 1% 1% 0% 0% 0% 0% 53.8°C 0/8 21:29:20: 1200MHz 0.07 0% 0% 0% 0% 0% 0% 53.8°C 0/8 21:29:25: 1200MHz 0.07 0% 0% 0% 0% 0% 0% 53.4°C 0/8 21:29:30: 1200MHz 0.06 3% 1% 0% 0% 0% 0% 53.2°C 0/8 21:29:35: 1200MHz 0.06 0% 0% 0% 0% 0% 0% 53.5°C 0/8 21:29:40: 1200MHz 0.05 1% 0% 0% 0% 0% 0% 52.8°C 0/8 21:29:46: 1200MHz 0.05 0% 0% 0% 0% 0% 0% 53.0°C 0/8 21:29:51: 1200MHz 0.04 1% 1% 0% 0% 0% 0% 52.9°C 0/8 21:29:56: 1200MHz 0.04 1% 1% 0% 0% 0% 0% 52.3°C 0/8 21:30:01: 1200MHz 0.04 1% 0% 0% 0% 0% 0% 52.4°C 0/8 21:30:06: 1200MHz 0.03 2% 1% 0% 0% 0% 0% 52.8°C 0/8 21:30:11: 1200MHz 0.03 1% 1% 0% 0% 0% 0% 53.1°C 0/8 21:30:16: 1200MHz 0.03 1% 1% 0% 0% 0% 0% 53.4°C 0/8 Turning to powersave cpu go down correctly to 240 Mhz Spoiler francesco@orangepizero:~$ sudo cpufreq-set -g powersave francesco@orangepizero:~$ sudo armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 21:32:56: 240MHz 0.14 4% 1% 1% 0% 0% 0% 51.1°C 0/8 21:33:01: 240MHz 0.13 1% 1% 0% 0% 0% 0% 50.6°C 0/8 21:33:06: 240MHz 0.12 1% 1% 0% 0% 0% 0% 51.1°C 0/8 21:33:12: 240MHz 0.11 1% 1% 0% 0% 0% 0% 50.1°C 0/8 21:33:17: 240MHz 0.17 1% 1% 0% 0% 0% 0% 49.9°C 0/8 21:33:22: 240MHz 0.15 1% 1% 0% 0% 0% 0% 51.3°C 0/8 21:33:28: 240MHz 0.14 1% 1% 0% 0% 0% 0% 50.6°C 0/8 21:33:33: 240MHz 0.13 1% 1% 0% 0% 0% 0% 50.5°C 0/8 21:33:38: 240MHz 0.12 2% 1% 0% 0% 0% 0% 51.2°C 0/8 21:33:44: 240MHz 0.11 1% 1% 0% 0% 0% 0% 51.3°C 0/8 21:33:49: 240MHz 0.10 1% 1% 0% 0% 0% 0% 50.5°C 0/8 21:33:54: 240MHz 0.09 1% 1% 0% 0% 0% 0% 50.3°C 0/8 21:34:00: 240MHz 0.08 1% 1% 0% 0% 0% 0% 50.1°C 0/8 21:34:05: 240MHz 0.08 1% 1% 0% 0% 0% 0% 50.1°C 0/8 I have not the file /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate in my installation: Spoiler francesco@orangepizero:/sys/devices/system/cpu/cpufreq$ ls -la total 0 drwxr-xr-x 3 root root 0 feb 8 21:13 . drwxr-xr-x 10 root root 0 gen 1 1970 .. drwxr-xr-x 3 root root 0 feb 8 21:13 policy0 francesco@orangepizero:/sys/devices/system/cpu/cpufreq$ cd policy0/ francesco@orangepizero:/sys/devices/system/cpu/cpufreq/policy0$ ls -la total 0 drwxr-xr-x 3 root root 0 feb 8 21:38 . drwxr-xr-x 3 root root 0 feb 8 21:38 .. -r--r--r-- 1 root root 4096 feb 8 21:35 affected_cpus -r-------- 1 root root 4096 feb 8 21:13 cpuinfo_cur_freq -r--r--r-- 1 root root 4096 feb 8 21:13 cpuinfo_max_freq -r--r--r-- 1 root root 4096 feb 8 21:13 cpuinfo_min_freq -r--r--r-- 1 root root 4096 feb 8 21:35 cpuinfo_transition_latency -r--r--r-- 1 root root 4096 feb 8 21:35 related_cpus -r--r--r-- 1 root root 4096 feb 8 21:35 scaling_available_frequencies -r--r--r-- 1 root root 4096 feb 8 21:13 scaling_available_governors -r--r--r-- 1 root root 4096 feb 8 21:35 scaling_cur_freq -r--r--r-- 1 root root 4096 feb 8 21:35 scaling_driver -rw-r--r-- 1 root root 4096 feb 8 21:13 scaling_governor -rw-r--r-- 1 root root 4096 feb 8 21:13 scaling_max_freq -rw-r--r-- 1 root root 4096 feb 8 21:13 scaling_min_freq -rw-r--r-- 1 root root 4096 feb 8 21:35 scaling_setspeed drwxr-xr-x 2 root root 0 feb 8 21:13 stats System logs: http://ix.io/FvU EDIT: @BRSS this value, in Debian Stretch, is saved to "cpuinfo_transition_latency" (7044144). But (if untouched) "ondemand" governor performs like "performance" one.
Moklev Posted February 12, 2018 Posted February 12, 2018 RE-EDIT: This issue partially solved with new Armbian 5.41 with kernel xx.18. Now OPIZ run stable @1008MHz.
BRSS Posted February 17, 2018 Author Posted February 17, 2018 On 12/02/2018 at 2:27 PM, Moklev said: RE-EDIT: This issue partially solved with new Armbian 5.41 with kernel xx.18. Now OPIZ run stable @1008MHz. @1008MHz with no load? Any values changed?
guidol Posted February 17, 2018 Posted February 17, 2018 On 12/02/2018 at 4:27 PM, Moklev said: RE-EDIT: This issue partially solved with new Armbian 5.41 with kernel xx.18. Now OPIZ run stable @1008MHz. Hmm on legacy I got: ARMBIAN 5.38 stable Ubuntu 16.04.3 LTS 3.4.113-sun8i root@orangepizero:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 13:25:35: 768MHz 0.49 3% 2% 0% 0% 0% 0% 65°C 1/7 13:25:40: 240MHz 0.45 3% 2% 0% 0% 0% 0% 65°C 1/7 13:25:46: 240MHz 0.42 5% 3% 1% 0% 0% 0% 65°C 1/7 13:25:51: 240MHz 0.38 5% 3% 1% 0% 0% 0% 66°C 1/7 but on mainline it wont get down to 240Mhz ARMBIAN 5.41.180208 nightly Ubuntu 16.04.3 LTS 4.14.18-sunxi root@orangepizero:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:27:08: 960MHz 1.77 45% 12% 28% 0% 3% 0% 70.2°C 3/8 10:27:13: 960MHz 1.71 27% 4% 22% 0% 0% 0% 71.1°C 3/8 10:27:19: 1008MHz 1.57 8% 2% 5% 0% 0% 0% 66.9°C 2/8 10:27:24: 1104MHz 1.45 3% 1% 0% 0% 0% 0% 64.5°C 1/8 10:27:29: 1104MHz 1.33 2% 1% 0% 0% 0% 0% 64.4°C 1/8 10:27:34: 1200MHz 1.22 3% 2% 0% 0% 0% 0% 63.8°C 0/8 10:27:39: 1200MHz 1.13 2% 1% 0% 0% 0% 0% 64.4°C 0/8 10:27:44: 1200MHz 1.04 2% 1% 0% 0% 0% 0% 64.0°C 0/8 10:27:49: 1200MHz 0.95 3% 2% 0% 0% 0% 0% 63.5°C 0/8 10:27:54: 1200MHz 0.88 2% 1% 0% 0% 0% 0% 63.2°C 0/8 10:27:59: 1200MHz 0.81 2% 1% 0% 0% 0% 0% 64.7°C 0/8
Moklev Posted February 17, 2018 Posted February 17, 2018 2 hours ago, BRSS said: @1008MHz with no load? Any values changed? Standard values (Armbian 5.41 Stretch, kernel xx.18, governor: ondemand). 1008MHz under load, now (after 6 days of uptime) rised up to 1200 Mhz. Spoiler francesco@orangepizero:~$ sudo armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 14:01:41: 1200MHz 0.86 19% 0% 18% 0% 0% 0% 64.3°C 0/8 14:01:46: 1200MHz 0.87 17% 1% 16% 0% 0% 0% 63.9°C 0/8 14:01:51: 1200MHz 0.88 17% 1% 15% 0% 0% 0% 64.0°C 0/8 14:01:56: 1200MHz 0.81 16% 0% 14% 0% 0% 0% 64.3°C 0/8 14:02:01: 1200MHz 0.75 17% 1% 15% 0% 0% 0% 63.8°C 0/8 14:02:06: 1200MHz 0.77 17% 1% 15% 0% 0% 0% 64.4°C 0/8 14:02:11: 1200MHz 0.87 16% 1% 15% 0% 0% 0% 64.4°C 0/8 14:02:16: 1200MHz 0.96 16% 1% 15% 0% 0% 0% 64.4°C 0/8 14:02:21: 1200MHz 1.12 16% 1% 15% 0% 0% 0% 63.9°C 0/8 14:02:27: 1200MHz 1.19 17% 1% 15% 0% 0% 0% 64.7°C 0/8 14:02:32: 1200MHz 1.18 16% 1% 15% 0% 0% 0% 63.2°C 0/8 14:02:37: 1200MHz 1.08 17% 1% 15% 0% 0% 0% 63.5°C 0/8 14:02:42: 1200MHz 1.07 17% 1% 15% 0% 0% 0% 63.4°C 0/8 14:02:47: 1200MHz 1.07 18% 1% 16% 0% 0% 0% 63.5°C 0/8 Without load, disabling motioneye and pihole, system stuck to 1,2GHz and won't get down to 240MHz as reported by @guidol. But... mainline image is in a testing stage and -good news- it's stable, not perfect but stable. :-)
Moklev Posted May 5, 2018 Posted May 5, 2018 @guidol http://linux-sunxi.org/Linux_mainlining_effort#Planned_for_4.18 CPUFreq for H2/H3/H5 on 4.18.yy
WarHawk_AVG Posted July 13, 2018 Posted July 13, 2018 I just changed my /etc/default/cpufrequtils on my OPiZero to, I am running 4.14.18-sunxi # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=240000 MAX_SPEED=912000 GOVERNOR=conservative My armbianmonitor -m looks like this now 10:37:07: 816MHz 0.31 7% 2% 4% 0% 0% 0% 42.7°C 0/8 10:37:12: 240MHz 0.36 3% 1% 2% 0% 0% 0% 42.2°C 0/8 10:35:47: 240MHz 0.30 12% 2% 7% 0% 0% 1% 42.5°C 0/8 10:35:52: 240MHz 0.28 6% 2% 2% 0% 0% 0% 43.2°C 0/8 10:35:58: 480MHz 0.26 4% 2% 1% 0% 0% 0% 43.0°C 0/8 10:36:03: 240MHz 0.23 7% 2% 3% 0% 0% 0% 43.2°C 0/8 10:36:08: 240MHz 0.30 7% 2% 5% 0% 0% 0% 44.0°C 0/8 10:36:13: 240MHz 0.35 11% 3% 6% 0% 0% 0% 41.7°C 0/8 10:36:19: 240MHz 0.32 10% 2% 6% 0% 0% 0% 43.8°C 0/8 10:36:24: 240MHz 0.38 8% 3% 3% 0% 0% 0% 40.8°C 0/8 10:36:29: 240MHz 0.35 5% 2% 2% 0% 0% 0% 44.5°C 0/8 10:36:35: 240MHz 0.40 5% 2% 2% 0% 0% 0% 40.8°C 0/8 10:36:40: 240MHz 0.37 4% 1% 2% 0% 0% 0% 43.8°C 0/8 10:36:45: 240MHz 0.34 4% 2% 1% 0% 0% 0% 43.6°C 0/8 10:36:51: 240MHz 0.31 3% 1% 1% 0% 0% 0% 41.1°C 0/8 10:36:56: 240MHz 0.37 7% 2% 3% 0% 0% 0% 44.2°C 0/8 10:37:01: 240MHz 0.34 7% 1% 4% 0% 0% 0% 42.1°C 0/8 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:37:07: 816MHz 0.31 7% 2% 4% 0% 0% 0% 42.7°C 0/8 10:37:12: 240MHz 0.36 3% 1% 2% 0% 0% 0% 42.2°C 0/8 I can confirm it does go up to 912MHz under a moderate load and drops down to very low cpu usage at idle...and temps dropped considerably...used to run in the 51-53~ range! All I have is a passive heatsink thermal glued to the processor (no active cooling) Per user283746 in another thread You can set options manually but they are not retained after reboot unless they are set in the /etc/default/cpufrequtils sudo cpufreq-info sudo cpufreq-set --min 240MHz sudo cpufreq-set --max 912MHz
tkaiser Posted July 13, 2018 Posted July 13, 2018 4 minutes ago, WarHawk_AVG said: MAX_SPEED=912000 OPi Zero and all the other smaller H3 boards implement DVFS with just two voltages: 1.1V and 1.3V (some interesting stuff wrt this) These 912 MHz are the value we chose with legacy kernel to remain on the lower voltage but with mainline kernel it's 816 MHz instead (with legacy we used our own optimized 'Armbian settings' while with mainline we rely on 'upstream settings'). So if you want to ensure lowest consumption and heat possible with mainline kernel this needs to be adjusted to MAX_SPEED=816000 instead. The 96 MHz difference isn't important, remaining on 1.1V is. Should be pretty easy to test for by setting both min and max speed one time to 816 and the other to 912MHz and then compare temperatures in idle. 1
guidol Posted July 13, 2018 Posted July 13, 2018 the time before I got as GOVERNOR ondemand and the frequence wasnt going down to 240Mhz while using kernel Linux opi-zero 4.17.5-sunxi #101 SMP Tue Jul 10 18:05:00 UTC 2018 armv7l armv7l armv7l GNU/Linux ( ARMBIAN 5.52.180710 nightly Ubuntu 16.04.4 LTS 4.17.5-sunxi ) and older... Now I changed the GOVERNOR from ondemand to conversative: ENABLE=true MIN_SPEED=240000 MAX_SPEED=816000# GOVERNOR=ondemandGOVERNOR=conservative and now also my OPi Zero does switch down to 240Mhz root@opi-zero(addr:192.168.6.99):~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq C.St. 13:59:27: 816MHz 0.98 40% 12% 25% 0% 3% 0% 1/8 13:59:32: 816MHz 0.98 26% 3% 22% 0% 0% 0% 2/8 13:59:37: 240MHz 0.98 14% 2% 11% 0% 0% 0% 1/8 13:59:43: 240MHz 0.90 2% 1% 0% 0% 0% 0% 1/8 13:59:48: 240MHz 0.91 1% 1% 0% 0% 0% 0% 1/8
guidol Posted July 13, 2018 Posted July 13, 2018 1 hour ago, tkaiser said: OPi Zero and all the other smaller H3 boards implement DVFS with just two voltages: 1.1V and 1.3V (some interesting stuff wrt this) These 912 MHz are the value we chose with legacy kernel to remain on the lower voltage but with mainline kernel it's 816 MHz instead Do you know id there is anywhere a small table for MIN and MAX_SPEED for H2+, H5 and maybe H6 depending on legacy or mainline kernel? If I do set the H5 of my NanoPi Neo2 to conservative and MIN_SPEED=2400000 then he will only go down to 408Mhz: root@nanopi-neo22(192.168.6.22):~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq C.St. 15:10:04: 648MHz 0.14 8% 2% 4% 0% 1% 0% 0/2 15:10:09: 408MHz 0.13 0% 0% 0% 0% 0% 0% 0/2 15:10:15: 408MHz 0.12 0% 0% 0% 0% 0% 0% 0/2 15:10:20: 408MHz 0.11 0% 0% 0% 0% 0% 0% 0/2 15:10:25: 408MHz 0.10 0% 0% 0% 0% 0% 0% 0/2 15:10:30: 408MHz 0.09 0% 0% 0% 0% 0% 0% 0/2 EDIT: Ahh - I found that documentation:http://linux-sunxi.org/Cpufreq root@nanopineo23(192.168.6.23):~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 408000 648000 816000
tkaiser Posted July 13, 2018 Posted July 13, 2018 55 minutes ago, guidol said: If I do set the H5 of my NanoPi Neo2 to conservative and MIN_SPEED=2400000 then he will only go down to 408Mhz: Yes, it's only available what's defined in DT. This is related to this topic. But please be careful: setting minimum cpufreq to really low values is counterproductive with some cpufreq governors since it will take a high amount of time to increase cpufreq when needed. @zador.blood.stained and me tested extensively two years ago with a lot of H3 boards and back then we found that setting boards to ~500 MHz minimum was the best compromise. When looking at temperatures or consumption there's literally zero difference between idling at 240 MHz or 480 MHz. The only important thing is DVFS (entering a state where the CPU is fed with lowest voltage possible -- so on those H3 boards with primitive voltage regulation most probably idle behaviour at 240 MHz and 816 MHz doesn't differ that much or at all). Keeping minimum clockspeed at a sensible high value is especially important when thinking about storage performance since some cpufreq governors don't count I/O activity as an indication to increase CPU clockspeeds. For example SD card performance on Tinkerboard with TinkerOS sucked but not with Armbian. Only real difference: the kernel allows to downclock to 200 MHz while with Armbian our cpufrequtils package keeps minimum clockspeed at 600 MHz. In Armbian we have special precautions for the ondemand governor: https://github.com/armbian/build/blob/52c71aba807f28e8325f324fba39f25e6991f7f2/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L59-L70 It seems I need to add something to tune sampling_rate as @BRSS suggested above (seems something changed with 4.14). Currently testing with if [ -f /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency ]; then echo $(($(cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency) / 10 )) >${i}/sampling_rate fi Feedback welcomed! Anyone willing to help please edit /etc/init.d/armhwinfo and add the above after the 'echo 10 >${i}/sampling_down_factor' line, reboot and report back. 1
tkaiser Posted July 16, 2018 Posted July 16, 2018 On 2/8/2018 at 9:40 PM, Moklev said: I have not the file /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate in my installation You had. But since you switched to a different governor and those sysfs entries are created/removed dynamically they disappeared. As soon as you switch the governor /sys/devices/system/cpu/cpufreq/$governor will reappear. As a general information: we tried to move away from ondemand two years ago with kernel 4.7 when schedutil governor was introduced which should be a replacement for ondemand that is considered somewhat broken by kernel devs. Unfortunately with schedutil a lot of strange things happened (at least on ARM) so we were back at ondemand. Ondemand unlike other governors has some tunables that are important for many use cases: https://github.com/armbian/build/blob/52bef7ddf9d424eb65d831385714a9da66153078/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L59-L71 The most important one for good storage performance is io_is_busy set to 1. If this is not set IO accesses are often way slower since cpufreq remains at a low value all the time instead of jumping to the maximum. Now we seem to have a problem with ondemand governor not switching to lower cpufreqs caused by a changed sampling_rate default (too low). So now we need feedback from users playing around with this value with different kernels. 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. If you use an Armbian nightly or switched to dev branch then you need to edit /usr/lib/armbian/armbian-hardware-optimization instead of /etc/init.d/armhwinfo.
WarHawk_AVG Posted July 17, 2018 Posted July 17, 2018 On 7/13/2018 at 5:52 AM, WarHawk_AVG said: Roger that...will check it out tkaiser when set to 816MHz....it in fact does drop approx 7-10C consistently... Odd thing is...on my Orange Pi Lite on my octoprint in the front room, it stays in the 32~ range...but in my closet running TOR/OpenVPN it's stays in the 42-54~ range...no HS on the one in the front room, but there is a ceiling fan near it...maybe just that little bit of air movement helps. But I can attest that limiting to 816 does in fact reduce heat produced considerably...biggest bonus...no more lockups under heavy load for extended periods. Thanks again!
Recommended Posts