| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| wiki:system_configuration [2022/05/05 22:57] – [Disabling resource-intensive daemons, services and processes] autostatic | wiki:system_configuration [2025/04/13 18:42] (current) – [rtcqs] autostatic |
|---|
| |
| After adjusting your system using the recommendations of [[system_configuration#rtcqs]] and with JACK (QjackCtl) and a2jmidid installed, the basics should be there for a well performing real-time audio system (depending on your hardware too of course). | After adjusting your system using the recommendations of [[system_configuration#rtcqs]] and with JACK (QjackCtl) and a2jmidid installed, the basics should be there for a well performing real-time audio system (depending on your hardware too of course). |
| | |
| | This wiki also contains a manual on installing a Linux audio system here: [[wiki:system_build|]] |
| |
| ==== Preliminary ==== | ==== Preliminary ==== |
| Run ''uname -a'' to find out which kernel you're running: | Run ''uname -a'' to find out which kernel you're running: |
| |
| Linux bto 5.17.1-rt17 #1~focal1 SMP PREEMPT_RT Sat Apr 2 10:32:50 CEST 2022 x86_64 x86_64 x86_64 GNU/Linux | Linux bto 6.5.6-1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 6.5-7.1~bookworm (2023-10-06) x86_64 GNU/Linux |
| |
| 5.17.1-rt17 is the version number of the currently running kernel. The configuration file with which this kernel was created can be found in ''/boot/config-5.17.1-rt17''. Open it, and check if it has the following characteristics: | 6.5.6-1-liquorix-amd64 is the version number of the currently running kernel. The configuration file with which this kernel was created can be found in ''/boot/config-6.5.6-1-liquorix-amd64''. Open it, and check if it has the following characteristics: |
| |
| CONFIG_HIGH_RES_TIMERS=y | CONFIG_HIGH_RES_TIMERS=y |
| |
| If you can't find the config file for your kernel there is also the possibility to extract the config from ''/proc/config.gz'' if your kernel supports it (''CONFIG_IKCONFIG_PROC=y''): | If you can't find the config file for your kernel there is also the possibility to extract the config from ''/proc/config.gz'' if your kernel supports it (''CONFIG_IKCONFIG_PROC=y''): |
| gunzip -c /proc/config.gz > config-`uname -r` | gunzip -c /proc/config.gz > config-$(uname -r) |
| |
| === Do I really need a real-time kernel? === | === Do I really need a real-time kernel? === |
| |
| With the kernel boot option ''threadirqs'' standard kernels create threaded IRQs which basically nullifies the need to use a real-time kernel in most of the cases. But a real-time kernel can still be very useful on a Linux audio platform. If you need the lowest latencies possible a real-time kernel is still an option. But if you're mainly recording, a standard kernel or an optimized kernel (like the low-latency kernel Ubuntu offers) will probably suffice. | With the kernel boot option ''threadirqs'' standard kernels create threaded IRQs which basically nullifies the need to use a real-time kernel in most of the cases. But a real-time kernel can still be very useful on a Linux audio platform. If you need the lowest latencies possible or if you're working on a less powerful system (i.e. Raspberry Pi) a real-time kernel can still be an option. But if you're mainly recording, a standard kernel or an optimized kernel (like the low-latency kernel Ubuntu offers) will probably suffice. |
| |
| See also: [[http://example.comhttps://jackaudio.org/faq/realtime_vs_realtime_kernel.html|Do I need a realtime kernel to use realtime scheduling?]] | See also: [[https://jackaudio.org/faq/realtime_vs_realtime_kernel.html|Do I need a realtime kernel to use realtime scheduling?]] |
| |
| === Using the threadirqs kernel option === | === Using the threadirqs kernel option === |
| |
| This is only needed for so-called generic kernels, ie. standard kernels that are not tweaked for lowlatency performance. You can check if your kernel already includes this option with the following command: | This is only needed for so-called generic or low-latency kernels. You can check if your kernel already includes this option with the following command: |
| |
| $ grep -e "CONFIG_IRQ_FORCED_THREADING=y" -e "CONFIG_PREEMPT_RT=y" /boot/config-`uname -r` | $ grep -e "CONFIG_IRQ_FORCED_THREADING=y" -e "CONFIG_PREEMPT_RT=y" /boot/config-$(uname -r) |
| | |
| If it returns ''CONFIG_IRQ_FORCED_THREADING=y'' and ''CONFIG_PREEMPT_RT=y'' then your kernel is using IRQ threading and you don't have to proceed with the following steps. If it only returns ''CONFIG_IRQ_FORCED_THREADING=y'' you can add the ''threadirqs'' boot option as described below. If the command returns nothing you have a kernel that cannot use threaded IRQs. | If it returns ''CONFIG_IRQ_FORCED_THREADING=y'' and ''CONFIG_PREEMPT_RT=y'' then your kernel is using IRQ threading and you don't have to proceed with the following steps. If it only returns ''CONFIG_IRQ_FORCED_THREADING=y'' you can add the ''threadirqs'' boot option as described below. If the command returns nothing you have a kernel that cannot use threaded IRQs. |
| |
| === Disabling Spectre and Meltdown mitigations === | === Disabling Spectre and Meltdown mitigations === |
| :!: Warning: disabling these mitigations will make your machine less secure! Use with caution! | :!: Warning: Using ''mitigations=off'' will make your machine less secure! Use with caution! For more information on the risks see https://meltdownattack.com/ |
| |
| To work around the Spectre and Meltdown vulnerabilities several mitigations were built into the kernel. These mitigations can have a negative impact on the performance of your machine. To disable those mitigations and get the most out of your CPU's again you can add the following kernel parameter to your Grub configuration, add it to the value of either ''GRUB_CMDLINE_LINUX_DEFAULT'' or ''GRUB_CMDLINE_LINUX'': | To work around the Spectre and Meltdown vulnerabilities several mitigations were built into the kernel. These mitigations can have a negative impact on the performance of your machine. To disable those mitigations and get the most out of your CPU's again you can add the following kernel parameter to your Grub configuration, add it to the value of either ''GRUB_CMDLINE_LINUX_DEFAULT'' or ''GRUB_CMDLINE_LINUX'': |
| === Installing a real-time kernel === | === Installing a real-time kernel === |
| |
| This section describes installing a real-time kernel on an existing Linux distribution. Some distributions contain packages you can install to get a real-time kernel, for others you'll need to compile it yourself. You can recognize real-time kernel versions by the added '-rt' or '-realtime' parts of the kernel version number. | This section describes installing a real-time kernel on an existing Linux distribution. Some distributions contain packages you can install to get a real-time kernel, for others you'll need to compile it yourself. You can recognize real-time kernel versions by the added '-rt' or '-realtime' parts of the kernel version number. As mentioned earlier, a real-time kernel is not a mandatory part of a Linux audio setup. |
| |
| == Ubuntu == | == Ubuntu == |
| |
| For rolling your own kernel, see [[build_your_own_real-time_kernel]]. | For rolling your own kernel, see [[build_your_own_real-time_kernel]]. |
| | |
| | === Other alternatives === |
| | Besides low-latency or real-time kernels there are also other kernel flavors available specifically tailored for multimedia usage. |
| | |
| | == Liquorix == |
| | > Liquorix is an enthusiast Linux kernel designed for uncompromised responsiveness in interactive systems, enabling low latency compute in A/V production, and reduced frame time deviations in games.((https://liquorix.net/)) |
| | Especially when used in combination with the ''threadirqs'' kernel option this kernel flavor performs very well. It is also the kernel that drives [[https://www.bandshed.net/avlinux/|AV Linux]]. |
| |
| == Other relevant links == | == Other relevant links == |
| You should check if the following daemons, services or processes are running, and if so, consider stopping them and/or resort to alternatives: | You should check if the following daemons, services or processes are running, and if so, consider stopping them and/or resort to alternatives: |
| |
| * CPU frequency scaling daemons that scale the frequency of the CPU depending on the CPU load could cause xruns in some cases. More recent versions of Jack1 (>= 0.118.0) are suffering less from xruns or run xrun free with a CPU frequency scaling daemon enabled that's set to a scaling governor like ondemand. A specialized CPU scaling daemon is in the works that depends on the DSP-load instead of the CPU load: [[http://rg42.org/oss/jackfreqd/start|jackfreqd]]. | * CPU frequency scaling that scales the frequency of the CPU depending on the CPU load could cause xruns in some cases. More recent versions of Jack1 (>= 0.118.0) are suffering less from xruns or run xrun free with CPU frequency scaling enabled that's set to a scaling governor like ondemand. A specialized CPU scaling daemon is in the works that depends on the DSP-load instead of the CPU load: [[https://github.com/oleg68/jackfreqd|JackFreqD]]. |
| * Desktop Environments (DE): especially on less powerful machines it is recommended to use a lighter DE than Gnome, KDE or Unity. Possible alternatives include LXDE, XFCE or IceWM. Another option is to only use a lightweight Window Manager (WM) like Openbox or Fluxbox. | * Desktop Environments (DE): especially on less powerful machines it is recommended to use a lighter DE than Gnome, KDE or Unity. Possible alternatives include LXDE, XFCE or IceWM. Another option is to only use a lightweight Window Manager (WM) like Openbox or Fluxbox. |
| * Compositing: same recommendation as for the DE you use. Try to avoid using a compositing manager like Compiz to lower the chance of running into xruns. | * Compositing: same recommendation as for the DE you use. Try to avoid using a compositing manager like Compiz to lower the chance of running into xruns. |
| |
| There are quite some processes and drivers running that you might not need when making music. Below an extremely simple example of a Bash script to disable all unneeded things. Note that it includes a solution for IRQ conflict, documented further down. | There are quite some processes and drivers running that you might not need when making music. Below an extremely simple example of a Bash script to disable all unneeded things. Note that it includes a solution for IRQ conflict, documented further down. |
| | |
| | :!: The script below is an example, do not use as is but first adapt it to your own system |
| |
| #!/bin/bash | #!/bin/bash |
| modprobe -r $module | modprobe -r $module |
| done | done |
| | |
| | # Unbind Bluetooth |
| | echo -n "2-1.6" > /sys/bus/usb/drivers/usb/unbind |
| | |
| # Disable CPU frequency scaling | # Disable CPU frequency scaling |
| echo -n performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | echo -n performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor |
| |
| You could run this script once you're logged in (it needs root privileges though), run it from ''/etc/rc.local'' or even as an init script. A suggestion would be to run it only when a real-time kernel is loaded for example: | You could run this script once you're logged in (it needs root privileges though) or run it at boot, see the rt-audio-setup suggestion above. |
| | |
| if [ $(uname -r | cut -d "-" -f 3) = "realtime" ] | |
| then /path/to/the/above/script | |
| fi | |
| | |
| The modules and processes differ of course on a per machine basis so first figure out which modules are loaded with ''lsmod'' for instance and then decide which ones you really need. Same for any processes running on your machine, ''ps -ef'' or even ''pstree -p'' could be helpful when looking for unneeded processes. | The modules and processes differ of course on a per machine basis so first figure out which modules are loaded with ''lsmod'' for instance and then decide which ones you really need. Same for any processes running on your machine, ''ps -ef'' or even ''pstree -p'' could be helpful when looking for unneeded processes. |
| |
| | ==== Simultaneous Multithreading ==== |
| | Simultaneous Multithreading (SMT) or hyper-threading can cause spikes in DSP load at higher DSP loads. In such cases it might be beneficial to disable SMT. This can be done by setting the SMT ''control'' flag to ''off''. |
| | |
| | echo off | sudo tee /sys/devices/system/cpu/smt/control |
| | |
| | See also https://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/ and https://discourse.ardour.org/t/avoiding-hyperthreading/89367/3 |
| | |
| | More information on SMT/hyper-threading: https://en.wikipedia.org/wiki/Simultaneous_multithreading |
| ==== Solve IRQ conflicts by unbinding devices ==== | ==== Solve IRQ conflicts by unbinding devices ==== |
| |
| More information: http://lwn.net/Articles/143397/ | More information: http://lwn.net/Articles/143397/ |
| |
| | ==== Power management ==== |
| | === Quality of Service interface === |
| | The Linux kernel provides a user mode interface for registering performance expectations((https://www.kernel.org/doc/html/latest/power/pm_qos_interface.html)). One of the parameters it could work on is CPU latency. A modern CPU can have different so-called sleep states and waking up from those sleep states can take some time (CPU latency). By opening the device node ''/dev/cpu_dma_latency'' and registering a value with it you can control these CPU |
| | latencies. I.e. when registering the value 0 you can tell the CPU to never go to sleep and to always be avialable, without any latency. In some cases this can decrease DSP load and in its turn decrease the chance of running into xruns. In order for this to work the device node has to be kept open with the registered value, simply writing a value to it will not work. DAW's like Ardour and Reaper offer the possibility to control the CPU latency and if you want to take advantage of this you will want your user to be able to write to this device node. To configure this add the udev rule from https://github.com/Ardour/ardour/blob/master/tools/udev/99-cpu-dma-latency.rules to ''/etc/udev/rules.d/'' and reload udev: |
| | sudo udevadm control --reload-rules |
| | sudo udevadm trigger |
| | |
| | To check if udev picked up your new rule: |
| | udevadm info -a -n /dev/cpu_dma_latency |
| | |
| | And ''/dev/cpu_dma_latency'' should now have read-write permissions for root and the audio group (mode 0660). Now you can set CPU latency as low as you like. Bear in mind that setting it to 0 will put your CPU's in an always-on state which wil run them hotter. So be prepared for some extra fan noise. |
| ==== Filesystems ==== | ==== Filesystems ==== |
| |
| |
| === ext3/ext4 tuning options === | === ext3/ext4 tuning options === |
| | |
| | Tuning shouldn't be necessary unless you experience IO issues on slower disks. |
| |
| == noatime == | == noatime == |
| Setting the ''noatime'' parameter in your ''/etc/fstab'' file reduces the amount of disk IO (the inode access times are not updated each time a file is read) which could improve the overall performance of your system. | Setting the ''noatime'' parameter in your ''/etc/fstab'' file reduces the amount of disk IO (the inode access times are not updated each time a file is read) which could improve the overall performance of your system. |
| |
| ''/dev/sdax / ext4 noatime,errors=remount-ro 0 1'' | /dev/sdax / ext4 noatime,errors=remount-ro 0 1 |
| |
| Most modern distributions use either ''atime'' or ''relatime''. See the mount manpage for more information on these parameters. | Most modern distributions use either ''atime'' or ''relatime''. See the mount manpage for more information on these parameters. |
| According to this thread [[http://comments.gmane.org/gmane.comp.file-systems.ext4/26720|High latency with ext4 / jbd2 kernel thread]] on the ext4 mailing list, the ''nobarrier'' parameter, with an ext4 filesystem, can reduce the amount of work made by the background kernel thread jbd2 and increase write speeds. However, this is an unsafe parameter, making your filesystem less resistant to power failures. | According to this thread [[http://comments.gmane.org/gmane.comp.file-systems.ext4/26720|High latency with ext4 / jbd2 kernel thread]] on the ext4 mailing list, the ''nobarrier'' parameter, with an ext4 filesystem, can reduce the amount of work made by the background kernel thread jbd2 and increase write speeds. However, this is an unsafe parameter, making your filesystem less resistant to power failures. |
| |
| ''/dev/sdax / ext4 nobarrier,errors=remount-ro 0 1'' | /dev/sdax / ext4 nobarrier,errors=remount-ro 0 1 |
| |
| Ext3 filesystem doesn't enable barrier by default, ext4 does. See the mount manpage for more information on these parameters. | Ext3 filesystem doesn't enable barrier by default, ext4 does. See the mount manpage for more information on these parameters. |
| ==== audio group ==== | ==== audio group ==== |
| |
| It is generally good practice to have an 'audio' group, and add any users that should be allowed to perform audio tasks to this group. This prevents some interference from non-audio-processes with audio tasks. To verify you're in the 'audio' group, run the ''groups'' command. Remember, after adding yourself to new groups, you need to log out and back in again. Be careful when adding an 'audio' group to your system: most systems come with a pre-configured 'audio' group, and do not warn you when you add another group with the same name, leading to much confusion. | It is generally good practice to have an ''audio'' group, and add any users that should be allowed to perform audio tasks to this group. This prevents some interference from non-audio-processes with audio tasks. To verify you're in the ''audio'' group, run the ''groups'' command. Remember, after adding yourself to new groups, it is best to log out and back in again. On systems that have an audio group you can add your user with the following command: |
| | sudo usermod -a -G audio <username> |
| | |
| | Where ''<username>'' is your username. |
| | |
| | Be careful when adding an ''audio'' group to your system: most systems come with a pre-configured ''audio'' group, and do not warn you when you add another group with the same name, leading to much confusion. When using Arch Linux the above is valid too except that Arch uses a different group name, i.e. ''realtime''((https://wiki.archlinux.org/title/Realtime_process_management#Configuring_PAM)). |
| |
| ==== Timers ==== | ==== Timers ==== |
| $ ps axHo user,lwp,pid,rtprio,ni,command | $ ps axHo user,lwp,pid,rtprio,ni,command |
| |
| $ ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i irq | $ ps -eLo user,pid,cls,rtprio,cmd --sort rtprio |
| |
| Or if you have [[system_configuration#rtirq]] installed: | Or if you have [[system_configuration#rtirq]] installed: |
| When using FireWire audio interfaces it is generally advised to use a real-time kernel. Of course this is not necessary, there are also users reporting success with generic kernels, but when you have trouble getting your system stable regarding xruns one of the first things besides installing [[system_configuration#rtirq|rtirq]] you might want to try is to [[system_configuration#the_kernel|install or compile a real-time kernel]]. | When using FireWire audio interfaces it is generally advised to use a real-time kernel. Of course this is not necessary, there are also users reporting success with generic kernels, but when you have trouble getting your system stable regarding xruns one of the first things besides installing [[system_configuration#rtirq|rtirq]] you might want to try is to [[system_configuration#the_kernel|install or compile a real-time kernel]]. |
| |
| | FireWire devices can be used with FFADO or ALSA, if supported. |
| |
| ==== JuJu FireWire stack ==== | |
| |
| As of kernel 2.6.37 the legacy FireWire stack has been removed from the kernel sources in favor of the [[https://ieee1394.wiki.kernel.org/index.php/Juju_Migration|JuJu stack]]. If you have FFADO installed it should take care of properly setting up your device(s). Instead of creating a ''/dev/raw1394'' node, the JuJu stack creates nodes per device in ''/dev/'', first device is always ''/dev/fw0''. Take note that the first device is always your controller, not your soundcard. | |
| |
| To use JACK with your FireWire device(s), set the driver to 'firewire' in QjackCtl or use the ''-dfirewire'' option on the commandline. | |
| |
| ===== Troubleshooting ===== | ===== Troubleshooting ===== |
| The [[https://codeberg.org/rtcqs/rtcqs|rtcqs]] script automatically analyzes your current configuration. This script will make configuration suggestions based on your current setup and link to the relevant sections on this page for background information. | The [[https://codeberg.org/rtcqs/rtcqs|rtcqs]] script automatically analyzes your current configuration. This script will make configuration suggestions based on your current setup and link to the relevant sections on this page for background information. |
| |
| rtcqs - version 0.4.2 | rtcqs - version 0.6.6 |
| | |
| Root User | Root User |
| [ OK ] Not running as root. | [ OK ] Not running as root. |
| | |
| Audio Group | Group Limits |
| =========== | ============ |
| [ OK ] User music is in the audio group. | [ OK ] User music is member of a group that has sufficient rtprio (95) and memlock (unlimited) limits set. |
| | |
| Background Processes | |
| ==================== | |
| [ OK ] No resource intensive background processes found. | |
| | |
| CPU Frequency Scaling | CPU Frequency Scaling |
| ===================== | ===================== |
| [ OK ] The scaling governor of all CPU's is set at performance. | [ OK ] The scaling governor of all CPUs is set to performance. |
| | |
| | Simultaneous Multithreading |
| | =========================== |
| | [ OK ] Simultaneous Multithreading (SMT, also called hyper-threading) is disabled. |
| | |
| Kernel Configuration | Kernel Configuration |
| ====================== | ====================== |
| [ OK ] High resolution timers are enabled. | [ OK ] High resolution timers are enabled. |
| | |
| System Timer | |
| ============ | |
| [ OK ] System timer is set at 1000 Hz and high resolution timers are enabled. | |
| | |
| Tickless Kernel | Tickless Kernel |
| Preempt RT | Preempt RT |
| ========== | ========== |
| [ OK ] Kernel 5.17.1-rt17 is a real-time kernel. | [ OK ] Kernel 6.13.8-4-liquorix-amd64 is using threaded IRQs. |
| | |
| Spectre/Meltdown Mitigations | Spectre/Meltdown Mitigations |
| Swappiness | Swappiness |
| ========== | ========== |
| [ OK ] Swappiness is set at 10. | [ OK ] Your system is configured without swap, setting swappiness does not apply. |
| | |
| Maximum User Watches | |
| ==================== | |
| [ OK ] max_user_watches has been set to 524288 which is sufficient. | |
| | |
| Filesystems | Filesystems |
| =========== | =========== |
| [ OK ] The following mounts can be used for audio purposes: /, /mnt/data | [ OK ] The following mounts can be used for audio purposes: / |
| [ WARNING ] The following mounts should be avoided for audio purposes: /run/user/1000/gvfs. See also https://wiki.linuxaudio.org/wiki/system_configuration#filesystems | |
| | |
| IRQs | IRQs |
| ===== | ==== |
| [ OK ] USB port ehci_hcd:usb1 with IRQ 16 does not share its IRQ. | [ OK ] USB port xhci_hcd with IRQ 45 does not share its IRQ. |
| USB port ehci_hcd:usb2 with IRQ 23 does not share its IRQ. | [ OK ] Soundcard snd_hda_intel:card10 with IRQ 91 does not share its IRQ. |
| USB port xhci_hcd with IRQ 26 does not share its IRQ. | [ OK ] USB port xhci_hcd with IRQ 43 does not share its IRQ. |
| Soundcard snd_hda_intel:card10 with IRQ 31 does not share its IRQ. | [ OK ] Soundcard snd_hda_intel:card11 with IRQ 92 does not share its IRQ. |
| | [ OK ] USB port xhci_hcd with IRQ 49 does not share its IRQ. |
| | [ OK ] USB port xhci_hcd with IRQ 47 does not share its IRQ. |
| | |
| Power Management | Power Management |
| ================ | ================ |
| [ OK ] Power management can be controlled from user space. This enables DAW's like Ardour and Reaper to set CPU DMA latency which could help prevent xruns. | [ OK ] Power management can be controlled from user space. This enables DAWs like Ardour and Reaper to set CPU DMA latency which could help prevent xruns. |
| | |
| To get the script install [[https://en.wikipedia.org/wiki/Git_%28software%29|Git]] first and then pull in the script: | |
| git clone https://codeberg.org/rtcqs/rtcqs.git | |
| cd rtcqs | |
| ./rtcqs.py | |
| |
| Discuss this script at the [[https://linuxmusicians.com/viewtopic.php?f=24&t=24000|LinuxMusicians Forum]] | Discuss this script at the [[https://linuxmusicians.com/viewtopic.php?f=24&t=24000|LinuxMusicians Forum]] |
| ''top'' is probably the most used tool to display system information like CPU or memory usage. It is installed by default on most distros. | ''top'' is probably the most used tool to display system information like CPU or memory usage. It is installed by default on most distros. |
| |
| {{:wiki:top2.png|Terminal running top}} | {{:wiki:top_2023-10-15.png|Terminal running top}} |
| |
| With the help of ''top'' you can find out which process is using up all your CPU or memory. By pressing ''h'' you get a help screen. To sort on memory usage instead of CPU usage you can press ''F'' + ''n'' + ''Enter''. | With the help of ''top'' you can find out which process is using up all your CPU or memory. By pressing ''h'' you get a help screen. To sort on memory usage instead of CPU usage you can press ''F'' + ''n'' + ''Enter''. |
| ''htop'' is the somewhat more sophisticated big brother of ''top''. | ''htop'' is the somewhat more sophisticated big brother of ''top''. |
| |
| {{:wiki:htop2.png|Terminal running htop}} | {{:wiki:htop_2023-10-15.png|Terminal running htop}} |
| |
| ==== latencytop ==== | ==== latencytop ==== |
| ==== cyclictest ==== | ==== cyclictest ==== |
| |
| Just as ''latencytop'' measures system latencies, ''[[https://rt.wiki.kernel.org/index.php/Cyclictest|cyclictest]]'' measures kernel latencies. ''cyclictest'' has quite some options but one of the most used ways to run the command is: | Just as ''latencytop'' measures system latencies, ''[[https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start|cyclictest]]'' measures kernel latencies. ''cyclictest'' has quite some options but one of the most used ways to run the command is: |
| # cyclictest -t1 -p 80 -n -i 10000 -l 10000 -m | # cyclictest -t1 -p 80 -n -i 10000 -l 10000 -m |
| One single thread (''-t1''), priority of 80 (''-p 80''), use clock_nanosleep (''-n''), use 10000 us base interval of thread (''-i 1000''), use 1000 loops and then exit (''-l 10000''), lock current and future memory allocations (''-m''). More on clock_nanosleep can be found in its manpage (''man clock_nanosleep''). | One single thread (''-t1''), priority of 80 (''-p 80''), use clock_nanosleep (''-n''), use 10000 us base interval of thread (''-i 1000''), use 1000 loops and then exit (''-l 10000''), lock current and future memory allocations (''-m''). More on clock_nanosleep can be found in its manpage (''man clock_nanosleep''). |
| |
| Other examples of the usage of ''cyclictest'': | Other examples of the usage of ''cyclictest'': |
| * http://code.goto10.org/projects/puredyne-old/wiki/KernelAndSystemOptimization#TestingandBenchmarking | * https://web.archive.org/web/20130727095507/http://code.goto10.org/projects/puredyne-old/wiki/KernelAndSystemOptimization#TestingandBenchmarking |
| * https://rt.wiki.kernel.org/index.php/Cyclictest#Expected_Results | * https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/result-examples |
| |
| ===== TODO ===== | ===== TODO ===== |
| * Power management | * Power management |
| * Rewrite rtirq section or move to separate page | * Rewrite rtirq section or move to separate page |
| | * Pipewire |
