At first I thought it might be more trouble than its worth seeing its not officially released yet for Debian.
However ‘Tuned’ has been around for quite some time for RedHat, Fedora, CentOS users. It was created and developed by RedHat and ‘tunes’ various parameters kernel etc for optimal performance.
Excerpt from RedHats .pdf file for Low Latency Tuning Re: Tuned
For low latency workloads, let's focus on a new tuned profile in Red Hat Enterprise Linux 7:
network-latency. Administrators interact with tuned via the tuned-adm command:
# tuned-adm list
Available profiles:
- balanced
- desktop
- latency-performance
- myprofile
- network-latency
- network-throughput
- powersave
- sas
- throughput-performance
- virtual-guest
- virtual-host
Current active profile: network-latency
The latency-performance profile implements the following:
# egrep -v '^$|^\#|\[' /usr/lib/tuned/latency-performance/tuned.conf
force_latency=1
governor=performance
energy_perf_bias=performance
min_perf_pct=100
kernel.sched_min_granularity_ns=10000000
vm.dirty_ratio=10
vm.dirty_background_ratio=3
vm.swappiness=10
kernel.sched_migration_cost_ns=5000000
These tunings are meant to reduce the impact of power management, increase the amount of
time tasks spend on the CPU, reduce task migrations, and reduce the amount of outstanding
dirty pages kept in memory. Taken together, this set of tuning has been shown in the lab and
in the field to reduce jitter and improve determinism for latency-sensitive workloads.
The network-latency profile is a child of the latency-performance profile. In addition to the
tunings included in the latency-performance profile above, network-latency adds the following:
Full write up here : https://access.redhat.com/sites/default/files/attachments/201501-perf-brief-low-latency-tuning-rhel7-v1.1.pdf
However it needs this command to complete the installation: apt --fix-broken install
Tuned is slated to be a standard part of Debian BUSTER
My suggestion is to either;
1) Include it Dietpi and have the complete install done during the first run
-or-
2) Include it in the Advanced Options under dietpi-config
Either way a suggested Dietpi menu selection would be to include only a few options in the GUI, such that once selected by the user the command runs to implement the 'tuned' profile
For example;
User selects 'Network-Latency'----OK, the script uses the command 'tuned-adm profile network-latency' to activate the profile and echos the results that its been activated.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Does it work?
Well if you can trust a Corporation with a 21 Billion Dollar market cap, whos business is all things Linux.....YES!
From my personal experience I'm happy with it too. :smiley:
We could consider to implement. However it would mean that we need to disable our own dietpi-config performance settings as this would interfere. Also not all settings are supported by all devices. The package on Debian Buster (testing) branch it available for “all” architectures: https://packages.debian.org/buster/tuned
Would need testing, if this really works on all SBCs, e.g. it carefully checks and attempts to apply only supported settings.
Requires python and a bunch of other packages, not all of them DietPi core requirements currently.
I would only implement optionally, e.g. via dietpi-software. To assure compatibility with dietpi-config, disable our own performance settings then, based on install state. Optionally replace own performance settings with tuned (tuned-adm) in a subshell, if installed? Print info to type “exit” to close subshell and return to dietpi-config.
[hr]
However, it should be mentioned, that these tunings can imply negative impact on SBCs, e.g.
Device running too hot. Some have issues with that, especially when throttle down is blocked via performance governor. Then in case emergency throttle down can lead to effectively the performance being lower when actually needed. ondemand governor allows the CPU to cool down, when not in use. Then it survives longer on high load before running too hot again. Something to consider definitely!
Dirty ratio reduction increases affective disk I/O, which is critical for SDcard lifetimes. Also in actually should decrease performance, since writing to disk of course is slower (in case bottleneck) than writing to RAM. I would only decrease this values, if your device has a fast and stable drive and you worry more about filled RAM (by dirty pages) instead of disk I/O performance.
vm.swappiness on DietPi is set to “1”, so the swapfile is used as late as possible. So this profile would decrease swap usage, so theoretically decrease RAM usage while increasing disk I/O. Same consideration as above.
So it should be clearly checked, for which devices “tuned” is really made. If desktop (x86 with HDD/SSD) are the main target, then the profiles might be suboptimal for SBCs (SDcards).
Side note, as I just checked, on my RPi2 default dirty page ratios are:
I have used it on all my SBC’s [RPI all versions, Odroid C2, Sparky, Asus TB].
I agree it might not be a good fit ‘out the box’ but I thought it might be worth a look. It also has the capability to haves its ‘stored’ tuned profiles to be adjusted and also for new tuned profiles to be added.
What ever you want me to test and report back just let me know.
At least it serves ideas about additional performance settings we can add.
And jep, if we implement it, we could add own (default) profiles, based on what we think is best for the SBC or matches our current defaults.
I don’t like python requirement , otherwise could be really considered to be implemented by default into all our images.
Hey, I am a few days late I guess. But I am looking to tweak the RPi 4 for latency and that would be really helpful. Sadly nothing of that kind has been implemented. Is something in the development?
Some are defaults, some have been added to DietPi a long time ago, some are nonsense or outdated as general recommendation, like performance governor, which you shouldn’t use, but schedutil (default on DietPi) reacts sufficiently fast in 99% of cases. But the governor otherwise can changed already, as well as drive’s I/O scheduler. If any specific service/process requires the last bit of priority/latency tuning, then IMO it makes much more sense to apply this on service/process level, to have individual ones handled with higher priority over common system tasks (cron, systemd timers and such), instead of adding the same to the whole system. This can be done e.g. via dietpi-services, including all relevant CPU and I/O scheduler and priority settings.
, otherwise could be really considered to be implemented by default into all our images. 
