1 1
BRSS

Orange Pi Zero - CPU and Load issues with 5.38

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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?

 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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. :-)

 

Schermata del 2018-02-17 14-04-10.png

Share this post


Link to post
Share on other sites

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

 



 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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=ondemand
GOVERNOR=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


 

Share this post


Link to post
Share on other sites
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
 

 

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
1 1