System/CPU performance tuning for increased autonomy.

[swatgoss]

Hi,

I'm planning on buying a RG351P soon and after watching a few videos about tuning the frontend interface i was asking myself about the tuning of the SoC power properties, like adjusting governors on x86.

I looked in the wiki and it (power/autonomy tuning) doesn't seem to be mentionned in the 3 pages.

Would there be a way to put the CPU in a very low power state if possible, according to the cores that are running ?

For example, when a gameboy or NES core is running the CPU gets the "conservative" governor applied automatically and this way the console gets the best possible autonomy while running the less demanding cores.

In a performance oriented set of mind would it be thinkable to program a kind of CPU pinning for cores/emulators (maybe add a parameter on the core command line) that wouldn't benefit from seeing all the cores of the CPU ?

Ideally parking the "inactive" cores for a greater autonomy could bring the very last drop of autonomy out of the system.

Also the discord link seems to be invalid.

[christianhaitian]

As the soc for this unit is based on the rk3326 chipset and most of the design of hardkernel's Odroid Go Advance, you can check Hardkernerl's Odroid Go Advance wiki for more information on what can be done. From what I've observed so far, performance is governed by various governors but not necessarily forcing a particular power state. I may be wrong on this though. I've corrected the discord link. Thanks for reporting that issue.

[ToniBC]

For my part, it would be nice to be able to set the CPU to 1.5 which is what the box indicates and not 1.3 as it currently works. That 200 MHz increase would help several systems.

If it can be put, it can be selected by game or platform.

Thank you.

[swatgoss]

I don't know this particular system yet but you may find some usefull information inside the sysfs (kernel virtual filesystem) in the folder : /sys/devices/system/cpu/cpu0/cpufreq/ if this feature is enabled.

There may be some interesting "files" in this folder, particularly those ones : /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

Those 2 files may contain the different allowed frequencies and governors like the names suggests. If the 1.5GHz frequency is not listed in here you could have to edit the dtb of your machine at your own risk (like any opensource project, especially when overclocking btw)

Also there may be some tools (cpufreq-info, inxi ...) that could report those informations but i don't know if the underlying ubuntu is capable of installing programs with apt nor if they exist in the ARM architecture.

edit : lscpu seems to be capable of reporting the allowed frequencies of RK3288 in this thread about overclocking ASUS tinkerboard S

If you are not familiar with SSH or TTY access to your console you may find accessing those manipulations somewhat difficult.

self note : Link to Odroid wiki

[christianhaitian]

This distro is configured to do ondemand between 400mhz to 1.5ghz and to lock at 1.5ghz when an emulator or port is launched. This configuration is handled in the .dtb for the device. However, I haven't noticed a performance difference with the 1.5ghz vs 1.3ghz. I suspect there are some other changes like voltage or timings that are needed to be adjust in order to make an appreciable difference.

[swatgoss]

Are you able to describe how the "lock @1.5GHz" mechanism detects that an emulator or core is launched ?

Would it be possible to modify the maximum frequency (in scaling_max_freq maybe) right before the lock when a particular core is launched ?

Ideally like some sort of hook that would read the maximum frequency for a particular emulator/core in a config file of that emulator/core !

To shed some light on the frequency effects, it would require some synthetic benchmark like openssl speed or some prime number crunching if they are subject to the same "maximum frequency lock when a payload runs" this should make it clear if the extra 200MHz brings any practical benefit (if someone would find a way to extensively run this kind of payload and also report the power consumption -battery runtime running those tests- it would be perfect and allow to weight all the variables at play for a handheld device)

[christianhaitian]

There's no sophisticated mechanism for detecting what emulator or core requires 1.5Ghz or not. Each emulator/port in this distro is configured in ES to first set the governor to performance mode with the following commands:

echo performance > /sys/devices/platform/ff400000.gpu/devfreq/ff400000.gpu/governor echo performance > /sys/devices/platform/dmc/devfreq/dmc/governor echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor

Upon existing those emulators/cores, the system is set back to on-demand mode:

echo simple_ondemand > /sys/devices/platform/ff400000.gpu/devfreq/ff400000.gpu/governor echo interactive > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor echo dmc_ondemand > /sys/devices/platform/dmc/devfreq/dmc/governor

The testing I used for measuring between 1.3ghz vs 1.5ghz was using sysbench as follows:

sysbench cpu --cpu-max-prime=100000 --time=10 --threads=4 run

In reviewing the generated events between the 2 speeds (with performance governor set), there was not a good appreciable difference.

My opinion is that you can save a little battery life by not forcing performance mode for low end cores like gameboy, nes, and such but the soc is just not very power efficient and the available power is what it is. More performance with emulators will need to be gain through better optimizations of the emulators. Even with that, we can't expect much better performance for things like the ppsspp emulator. Maybe Dreamcast and N64 can improve to be more performant on this soc.

[christianhaitian]

I forgot to include that the setting of the max frequency is set by the .dtb and I haven't seen a way to force a particular max speed on the fly without changing kernel files.

[swatgoss]

In the mentionned folders, do you have files like scaling_available_governors ?

I hope that the conservative governor is present so it can be a little more energy-efficient than plain performance when launching an emulator/port.

According to this kernel documentation there should also be a writable file scaling_max_freq but i can't find traces of the scaling_available_frequencies to know what value to echo into the max_freq file for a more fine grained control of the frequency ...

By any chance do you know of some documentation about the memory controller and the GPU of the RK3326 software controlled frequencies ? (under /sys/devices/platform/)

[ufoman]

The below frequencies seem to be available: ark@rg351p:~$ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 408000 600000 816000 1008000 1200000 1248000 1296000 1416000 1512000

Also: root@rg351p:~ echo 408000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq ^ makes videos in ES screensaver very jerky, so the max CPU speed is indeed changed root@rg351p:~ echo 1512000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq ^ returns things to normal

[swatgoss]

thanks for the info ! You may also try the 2nd lowest frequency as the lowest one may activate some "deep sleep" functions in the SoC.

Don't forget about the memory controller and the GPU parts of the SoC that are controlled under the platform folder whose state may also be coordinated to the CPU.

Is the screensaver still choppy when CPU is clocked at 600 or 800MHz ? By any chance, can you try and see if lowering the scaling_max_freq gives any difference in terms of autonomy when a core/emulator sets the performance governor ?

(my unit is ordered, delivery is planned next week so i can't be testing myself right now, i think i'll also try to use a modified DTB to undervolt the chip as much as possible and see if there is any gain)

Found this datasheet page 47 states that the CPU would operate at around 1.0V (1.4V max). The minimal voltage is 0.95V, that value leaves me guessing the margin of undervolting that would be available in the dtb... it seems close to the typical voltage so if the voltage regulators are not capable to be configured under 0.95V there may not be a lot of autonomy improvement.

[christianhaitian]

Closing as the only issue reported has been resolved.