This page lists a couple of performance considerations involving Lakka and the Raspberry Pi. Some of the mentioned issues should apply to any platform that Lakka runs on considering that some of the tweaks pertain more to the underlying Linux operating system rather than the hardware itself. Similarly, some mentioned problems pertain to the underlying electronics such that the notes should cover any tinker board like the Raspberry Pi.

At the current time of running Lakka ships with the ondemand governor enabled that is meant to mange the CPU speed depending on the machine workload. For a regular desktop, the ondemand governor makes sense because the OS might want to downclock the CPU in order to save power depending on the applications that are currently running. However, Lakka is a dedicated gaming OS such that allowing the OS to change the CPU frequency does not make much sense. Furthermore, whilst gaming, in case the CPU clock frequency changes, various lag spikes are introduced that might not provide a smooth gaming experience.

Using bcmstat the current machine metrics can be monitored. For instance, playing a game with the default settings, would result in the following readings with bcmstat:

19:31:28  800Mhz  500Mhz    0Mhz 43.82C (44.79C)  2,896          58         320
13:01:22 1000Mhz  500Mhz    0Mhz 42.84C (44.79C)      0           0           0
13:01:24 1500Mhz  500Mhz    0Mhz 44.30C (44.79C)  3,135          29          98
13:01:26 1000Mhz  500Mhz    0Mhz 45.28C (45.28C)  3,207         438         491
13:01:28  900Mhz  500Mhz    0Mhz 45.28C (45.28C)  2,332         190         294
13:01:30 1500Mhz  500Mhz    0Mhz 45.28C (45.28C)  2,364          88         107
13:01:32 1500Mhz  500Mhz    0Mhz 45.76C (45.76C)  2,289         150         107
13:01:35  900Mhz  500Mhz    0Mhz 44.79C (45.76C)  2,589          59         107

that show how the governor dynamically scales frequencies. Now, imagine playing game that requires a good reaction speed and a consistent gameplay such as a racing game. Whenever the governor scales the frequency down and then back up, a short lag spike is introduced that will affect the gameplay. Imagine, having to take an U-turn in a racing game and in case the CPU is suddenly downclocked to instead of running at full speed, a short delay might be experienced thereby making the player run off track. In a situation where high reaction speed is required, it does not really matter how fast the CPU is capable to go as much as having a consistent overall experience without sudden drops in performance.

One solution to avoid lag spikes, is to switch to the performance governor and then set the same minimum and maximum frequencies for the CPU. Editing ./.config/autostart.sh and adding:

# performance governor and smoothen out lag spikes
for i in 0 1 2 3; do
    echo "performance" > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor
    echo "1500000" > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq
    echo "1500000" > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_min_freq
done

will have the effect of setting the performance governor instead of the ondemand governor for all CPU cores (4, for the RPi4) and then adjust the minimum and maximum frequencies to the default maximum frequency supported by the RPi4 . Intuitively, this should prevent the operating system from scaling down the frequency and hold consistently at . Compared to the previous readings, bcmstat should now report the CPU frequency to be constantly :

13:07:34 1500Mhz  500Mhz    0Mhz 49.17C (49.17C)  2,157         178         420
13:07:36 1500Mhz  500Mhz    0Mhz 47.71C (49.17C)  1,995          88         107
13:07:38 1500Mhz  500Mhz    0Mhz 48.69C (49.17C)  1,864         164         107
13:07:40 1500Mhz  500Mhz    0Mhz 48.69C (49.17C)  1,821          29         106
13:07:42 1500Mhz  500Mhz    0Mhz 47.23C (49.17C)  2,167         150         107
13:07:44 1500Mhz  500Mhz    0Mhz 48.20C (49.17C)  2,169         147         107
13:07:46 1500Mhz  500Mhz    0Mhz 48.20C (49.17C)  2,173         355         106

Another solution is to set the force_turbo overclock setting in /flash/config.txt that leaves only as the choice of scaling frequencies. First mount the RPi boot partition as read-write with:

mount -o remount,rw /flash

and then edit /flash/config.txt to set:

force_turbo=1

The difference is that without the force_turbo setting, the RPi will report to the OS a list of frequencies that it can scale to and then, depending on the governor settings, the OS will downclock the CPU as it sees fit. With force_turbo set to 1, the RPi will only reporting the maximum frequency to the OS such that the governor will have no choice but to keep the CPU at the only and incidentally maximum frequency available.

In some Lakka builds, Retroarch is meant to display a thunderbolt whenever a power issue is detected (either overvoltage or undervoltage) but in some cases, the thunderbolt will not show up.

Logging in to Lakka remotely and issuing:

dmesg

should yield a message along the following lines:

kern  :crit  : [ 1701.464833 <    2.116656>] Under-voltage detected! (0x00050005)
kern  :info  : [ 1707.668180 <    6.203347>] Voltage normalised (0x00000000)

Whenever an undervoltage condition is detected, a machine like the RPi will automatically downclock the CPU until the voltage is normalized again. This can be observed with bcmstat showing the a frequency drop on the CPU. The downclock occurs regardless of the governor settings and regardless whether force_turbo is enabled since this time it is the hardware of the RPi4 that forces the downclock during an under-voltage event.

13:20:54 1500Mhz  500Mhz    0Mhz 49.66C (51.61C)  1,971          88         110
13:20:56 1500Mhz  500Mhz    0Mhz 49.17C (51.61C)  2,011          91         110
13:20:58  600Mhz  500Mhz    0Mhz 50.15C (51.61C)  1,990          58         110

The drop to is sufficient to introduce a small lag spike that may be distracting during gameplay.

Under-voltage conditions appear whenever a machine like the Raspberry Pi need to draw more power in order to fulfill the performance expectations but the amount of power required exceeds the capacity of the power line (both power supply and the power lines). One observed problem is that on a computer like the Raspberry Pi 4, is that if power is fed through just the 5V GPIO header instead of the USB power connector, the RPi4 is unable to draw sufficient power.

A simple solution is to feed power through the USB connector or through both the 5V GPIO header and the USB connector.

Overclocking can be enabled on the Raspberry Pi by changing the config.txt file in the flash boot partition on the SD card. The relevant settings are:

• force_turbo - has the effect of disabling frequency scaling and reporting to the operating system only the maximum frequency as being available for scaling ( on the RPi4),
• over_voltage - can be used to feed more volts to the CPU die,
• arm_freq - can be used to set the frequency of the CPU,
• gpu_freq and core_freq can be used to overclock the GPU and the cores.

Perhaps the most important is to be aware that any overclocking will draw more power such that under-voltage can be expected when the frequencies are bumped high enough. dmesg on Lakka should be used to check whether any under-voltage occurs when running at higher frequencies and bcmstat should be used to ensure that the frequencies do not change in order to not dynamically introduce lag while playing.

The Raspberry Pi 4 with the latest firmware is said to be able to accomplish a clock frequency of using the following settings:

force_turbo=1
over_voltage=6
arm_freq=2147

Depending on the silicone die, might not be possible but a near frequency such as or should be possible provided a good cooler is installed on the RPi CPU:

force_turbo=1
over_voltage=6
arm_freq=2100