In policy2 you can see, in policy0 you don’t see. Is that normal? It is not the ondemand folder in policy0.
It is not normal according to me. I see both:
vim3:~ # cat /sys/devices/system/cpu/cpufreq/policy*/ondemand/up_threshold
50
50Yes, so in the putty I see the values, I was referring to the structure of directories and files here
/sys/devices/system/cpu/cpufreq/policy0
vim3:~ # ls -l /sys/devices/system/cpu/cpufreq/policy0/
total 0
-r--r--r-- 1 root root 4096 Mar 1 19:50 affected_cpus
-r-------- 1 root root 4096 Mar 1 13:26 cpuinfo_cur_freq
-r--r--r-- 1 root root 4096 Mar 1 19:50 cpuinfo_max_freq
-r--r--r-- 1 root root 4096 Mar 1 19:50 cpuinfo_min_freq
-r--r--r-- 1 root root 4096 Mar 1 19:50 cpuinfo_transition_latency
drwxr-xr-x 2 root root 0 Mar 1 14:29 ondemand
-r--r--r-- 1 root root 4096 Mar 1 19:50 related_cpus
-r--r--r-- 1 root root 4096 Mar 1 19:50 scaling_available_frequencies
-r--r--r-- 1 root root 4096 Mar 1 11:18 scaling_available_governors
-r--r--r-- 1 root root 4096 Mar 1 11:18 scaling_cur_freq
-r--r--r-- 1 root root 4096 Mar 1 19:50 scaling_driver
-rw-r--r-- 1 root root 4096 Mar 1 11:18 scaling_governor
-rw-r--r-- 1 root root 4096 Mar 1 11:18 scaling_max_freq
-rw-r--r-- 1 root root 4096 Mar 1 11:18 scaling_min_freq
-rw-r--r-- 1 root root 4096 Mar 1 19:50 scaling_setspeed
drwxr-xr-x 2 root root 0 Mar 1 19:50 stats
vim3:~ #
vim3:~ # ls -l /sys/devices/system/cpu/cpufreq/policy2/
total 0
-r--r--r-- 1 root root 4096 Mar 1 19:50 affected_cpus
-r-------- 1 root root 4096 Mar 1 13:26 cpuinfo_cur_freq
-r--r--r-- 1 root root 4096 Mar 1 19:50 cpuinfo_max_freq
-r--r--r-- 1 root root 4096 Mar 1 19:50 cpuinfo_min_freq
-r--r--r-- 1 root root 4096 Mar 1 19:50 cpuinfo_transition_latency
drwxr-xr-x 2 root root 0 Mar 1 19:50 ondemand
-r--r--r-- 1 root root 4096 Mar 1 19:50 related_cpus
-r--r--r-- 1 root root 4096 Mar 1 19:50 scaling_available_frequencies
-r--r--r-- 1 root root 4096 Mar 1 19:50 scaling_available_governors
-r--r--r-- 1 root root 4096 Mar 1 19:50 scaling_cur_freq
-r--r--r-- 1 root root 4096 Mar 1 19:50 scaling_driver
-rw-r--r-- 1 root root 4096 Mar 1 11:18 scaling_governor
-rw-r--r-- 1 root root 4096 Mar 1 19:50 scaling_max_freq
-rw-r--r-- 1 root root 4096 Mar 1 19:50 scaling_min_freq
-rw-r--r-- 1 root root 4096 Mar 1 19:50 scaling_setspeed
drwxr-xr-x 2 root root 0 Mar 1 19:50 statsOkay, so it appears to me in the terminal, not seen in sftp (I use WinSCP). It doesn’t matter, it is important that it works.
Thanks.
1 Like
Just curious why everyone uses the ECHO method instead of TEE as I wrote near the very top?
Because echo run as root it can write directly to specified file.
Tee is usually used when echo-ing something as regular user and in this case echo doesn’t work.
Read bash - sudo echo "something" >> /etc/privilegedFile doesn't work - Stack Overflow
I use ‘tee’ only when I require the input to be sent to more than one file, otherwise I use ‘echo’.
tee - read from standard input and write to standard output and files
This will set the value just as soon as the ondemand governor is ready:
while [ $(cat /sys/devices/system/cpu/cpufreq/policy0/ondemand/up_threshold) != 100 ]
do echo 100 > /sys/devices/system/cpu/cpufreq/policy0/ondemand/up_threshold
done
1 Like
Hi,
In the frequency settings in the policy I noticed that we have this:
scaling_min_freq - 667000
and
scaling_available_frequencies - 100000 250000 500000 667000 1000000 1200000 1404000 1500000 1608000 1704000 1800000 1908000
This means that the frequencies 100000, 250000, 500000 cannot be used. It wouldn’t help either.
In time_in_state I saw that most are used 1000000 and 1200000.
Would it be wrong to eliminate 100000, 250000, 500000 and introduce something like 880000, 1100000 and 1300000?
scaling_available_frequencies - 667000 880000 1000000 1100000 1200000 1300000 1404000 1500000 1608000 1704000 1800000 1908000
Thanks.
Hi Guys what temps do you have on GT King?
The available frequencies are read only. They come from the dtb, which in turn comes from the manufacturers specifications for the chip. You can’t choose an arbitrary (unsupported) frequency. I expect the low rates are blocked because the OS does not perform properly at those rates.
I understand what you are saying, but those values do not seem to be chosen according to a precise mathematical calculation. I thought it wasn’t that complicated. However, it is not too important, ondemand governor is working well as he is now and I do not think it is worth the effort to make changes.
Thanks.
Thanks for this Tip! It works very well until 9.2.2 version.
Seems like /sys/devices is read only right now.
Kodi:~/.config # echo interactive | tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor >/dev/null
tee: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor: I/O error
Try /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
@ffimon - that Netdata screenshot you posted looks amazing.
Did you install this by using the CoreElec repository add-on, or did you setup manually? If you setup manually, do you have any links to a script to get the cpu details on the Amlogic hardware?
Thank you in advance!
![@ffimon’s original screenshot] (https://discourse.coreelec.org/uploads/default/original/2X/7/781ceedb44e6743d8d0d3bcb0e4cf0d31835d575.png)
Thanks for your reply
Same error 
Kodi:~ # echo interactive | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
interactive
tee: /sys/devices/system/cpu/cpufreq/policy0/scaling_governor: I/O error
on 9.2.2
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors
ondemand performance
AFAIK you can use ondemand instead interactive with very, very similiar temperature results (that was my systems result when comparing them a while ago). Ondemand should be a bit safer than interactive anyway (some users report some issues with interactive with some min/max CPU settings, but ondemand doesnt have those problemas AFAIK).