--- title: Low latency Linux for industrial embedded systems – Part III description: Why a low-latency Linux kernel is often the preferred solution for low-jitter, low-latency, soft real-time workloads. url: https://canonical.com/blog/industrial-embedded-systems-iii?format=md --- 1. [Blog](https://canonical.com/blog) 2. Article --- [Edoardo Barbieri](https://canonical.com/blog/author/edoardo-barbieri "More about Edoardo Barbieri") 14 February 2022 # Low latency Linux for industrial embedded systems – Part III [Embedded](https://canonical.com/blog/tag/embedded) [Industrial](https://canonical.com/blog/tag/industrial) [IoT](https://canonical.com/blog/tag/iot) [kernel](https://canonical.com/blog/tag/kernel) [Linux](https://canonical.com/blog/tag/linux) --- Share the article Welcome to the concluding chapter of this three-part blog series on the [low latency Linux kernel](https://packages.ubuntu.com/search?keywords=lowlatency&searchon=all&suite=impish§ion=all) for industrial embedded systems. Each blog is standalone and can be read independently from the others, although you may want to [start at the beginning](https://ubuntu.com/blog/industrial-embedded-systems) for some continuity. If you need a quick refresher on userland and kernel space, we recommend you check [Part I](https://ubuntu.com/blog/industrial-embedded-systems) out first. In [Part II](https://ubuntu.com/blog/industrial-embedded-systems-ii), we looked at preemption in Linux, the timer interrupt frequency, and the config options adopted by the [low latency Ubuntu Linux kernel](https://packages.ubuntu.com/search?keywords=lowlatency&searchon=all&suite=impish§ion=all). If you are a bit rusty with these concepts, going back to [Part I](https://ubuntu.com/blog/industrial-embedded-systems) and [Part II](https://ubuntu.com/blog/industrial-embedded-systems-ii) may help to refresh your memory. Otherwise, keep moving as you are almost at the end of your low latency journey! ## Latency in industrial embedded systems The [low latency Ubuntu kernel](https://packages.ubuntu.com/search?suite=all&searchon=all&keywords=lowlatency) is suitable for low-jitter workloads and industrial [embedded applications](https://ubuntu.com/engage/linux-embedded-applications-webinar?utm_source=linkedin&utm_medium=social&utm_campaign=7014K000000UZiRQAW) with latency requirements in the milliseconds’ range. **Latency** in an embedded system refers to the time elapsed when servicing a request, whereas **jitter** is the variability in the timing of an expected signal. Low jitter corresponds to reduced variability and undetectable variations in the kernel responsiveness when servicing sensitive applications [[1]](https://ubuntu.com/engage/kernel-telco-nfv?_ga=2.11800369.442719869.1644167938-2047897428.1631117853). [[2]](https://unsplash.com/photos/dhZtNlvNE8M) How does the low latency Ubuntu kernel meet such stringent requirements? For that, let’s quickly revisit the concepts delved at greater length in [Part I](https://ubuntu.com/blog/industrial-embedded-systems) and [Part II](https://ubuntu.com/blog/industrial-embedded-systems-ii) of this series. A program usually executes in User Mode in userland and activates a kernel routine when requesting one of its services. Once the [Linux kernel](https://ubuntu.com/kernel) has serviced the request, it resumes execution in the user address space. Linux [introduced kernel preemption in v2.5.4](https://cdn.kernel.org/pub/linux/kernel/v2.5/ChangeLog-2.5.4), enabling high-priority tasks to preempt running processes and issue system calls asking to switch to the kernel address space. Hence, in a preemptible kernel, a process can preempt an instance of a running program, forcibly interrupting the CPU and performing a context switch. The challenge in making a fully preemptive [Linux kernel](https://ubuntu.com/kernel) is detecting where preemption must not be allowed to occur, lest the interrupted execution thread results in catastrophic consequences. Of the available preemption models available upstream (**PREEMPT\_NONE**, **PREEMPT\_VOLUNTARY**, and **PREEMPT**), the [low latency Ubuntu kernel](https://packages.ubuntu.com/search?suite=all&searchon=all&keywords=lowlatency) has the maximum preemption in mainline. By enabling **CONFIG\_PREEMPT**, the low latency Ubuntu disables preemption only at critical locations, where the kernel must protect the data from concurrent access. Besides a few other minor config changes, the [low latency kernel](https://packages.ubuntu.com/search?keywords=lowlatency&searchon=all&suite=impish§ion=all) services most workloads when coupled with a 1000 Hz (**CONFIG\_HZ\_1000**) timer interrupt frequency. ## Low latency or real time? A kernel with the maximum preemption available in mainline (**PREEMPT**), coupled with four times the timer granularity of a generic kernel (**HZ\_1000** vs **HZ\_250**), invariably calls for comparisons with real-time alternatives. **PREEMPT\_RT**, slowly being mainlined, is arguably the preferred choice of Linux developers working on embedded systems requiring real-time capabilities. The latency requirements and the consequences of missing a deadline dictate whether a system needs **PREEMPT\_RT** or not. To make an informed decision, one must look at the data. If the latency demands are particularly tight and the consequences of a missed deadline are catastrophic, **PREEMPT\_RT** is likely a good choice. The [low latency Ubuntu kernel](https://packages.ubuntu.com/search?suite=all&searchon=all&keywords=lowlatency) is instead a great candidate if the system has latency requirements in the order of milliseconds. Low latency can also suit your application if missing a deadline results in system degradation but is not fatal, or even if the hardware handles most of the real-time performance. While low latency is not as firm as a full-blown **PREEMPT\_RT** integration, it is close and does not have the same compatibility issues. **CONFIG\_PREEMPT** uses entirely upstream code and is a configuration of mainline, with the kernel working as intended. On the other hand, **PREEMPT\_RT** is an intrusive patchset that may not be compatible with all required drivers and may require debugging/reworking. Another aspect to consider is that the kernel must not consume the entirety of a system’s resources to bring an acceptable return on investment. While preempt-full Linux kernels provide real-time performance, this may come with an operational cost, in that a real-time OS minimises response latency to events, not optimized throughput. On the other hand, the low latency Ubuntu kernel enables a well-balanced solution reducing overhead while maintaining responsiveness. Furthermore, the [low-latency Ubuntu kernel](https://packages.ubuntu.com/search?keywords=lowlatency&searchon=all&suite=impish§ion=all) is more favourable for throughput and user space CPU access than real-time alternatives [[1]](https://ubuntu.com/engage/kernel-telco-nfv?_ga=2.11800369.442719869.1644167938-2047897428.1631117853). Overall, unless it does not meet an exact preemption specification, the [low-latency kernel](https://packages.ubuntu.com/search?keywords=lowlatency&searchon=all&suite=impish§ion=all) fits well low-jitter, low-latency, soft “real-time” workloads. Dedicated devices (e.g.,life-supporting medical equipment) with catastrophic consequences in case of failure are instead better suited to a fully-preemptive solution than a balanced one. If you are ready for a more in-depth technical assessment, check this [specialised report comparing the Ubuntu low-latency kernel and an Ubuntu Linux kernel patched to be fully preemptive](https://ubuntu.com/engage/kernel-telco-nfv?_ga=2.241771527.442719869.1644167938-2047897428.1631117853). ## The low latency Ubuntu release cadence The low latency Ubuntu kernel is currently available on AMD64, with the kernel experts from [Canonical](https://canonical.com/) ready to target more architectures based on demand. Canonical releases the low latency alongside the [standard kernel](https://ubuntu.com/kernel), following the same cadence as the generic Ubuntu release. As a developer, you can access the same set of features, resiliency, and security with the low latency kernel that you have come to expect from [Ubuntu](https://ubuntu.com/). Canonical publishes new versions of Ubuntu with a [regular cadence](https://ubuntu.com/about/release-cycle), allowing developers regular secure access to the latest open source upstream capabilities. Each Ubuntu release is associated with its delivery date and codename (e.g. [Ubuntu ‘Focal Fossa’ 20.04](https://releases.ubuntu.com/20.04/) in April 2020). **LTS or Long Term Support** releases are enterprise-grade versions of Ubuntu, published in April every two years. Ubuntu LTS releases receive an initial maintenance period and optional five years of [**Extended Security Maintenance (ESM)**](https://ubuntu.com/security/esm). Enterprises and the community can access the entire lifecycle via an [Ubuntu Advantage subscription](https://ubuntu.com/advantage) or a [free personal subscription](https://ubuntu.com/advantage). You can [contact us for more information](https://ubuntu.com/support/contact-us). Canonical also ships production-ready Ubuntu every six months between LTS versions. These interim releases come with nine months of support, allowing users to run the latest kernels, libraries, and software versions. As a final note, the [low latency Ubuntu kernel](https://packages.ubuntu.com/search?keywords=lowlatency&searchon=all&suite=impish§ion=all) also ships with the same main kernel: v5.15 for [Jammy Jellyfish](https://discourse.ubuntu.com/t/jammy-jellyfish-release-schedule/23906), v5.13 for [Impish Indri](https://releases.ubuntu.com/21.10/), v5.11 for [Focal Fossa](https://releases.ubuntu.com/20.04/) and so on. ## Conclusion Real-time from a kernel perspective is a measure of latency from an interrupt request to a task entry. Intuitively, such delay affects the overall performance of a computer system, usually measured in terms of latency or throughput. Traditionally, Linux was designed for maximum throughput, whereas a real-time operating system (RTOS) attempts to minimise latency. The [low latency Ubuntu kernel](https://packages.ubuntu.com/search?keywords=lowlatency&searchon=all&suite=impish§ion=all) also minimises latency as much as possible, without relying on the more intrusive **PREEMPT\_RT** patch. The [low latency Ubuntu kernel](https://packages.ubuntu.com/search?suite=all&searchon=all&keywords=lowlatency) has the maximum preemption currently available in mainline (**PREEMPT**), coupled with four times the timer granularity of the generic Ubuntu kernel (**HZ\_1000** for low latency vs **HZ\_250** for generic). It is a “soft” real-time kernel with fully upstream code. Compared to real-time alternatives, it results in a lower system overhead, is less costly to maintain, more favourable for higher throughput, and available CPU for user space processes. Whether a real-time or low latency kernel better serves your application, depends on its latency requirements. [Let’s work together on your use case today](https://ubuntu.com/support#get-in-touch). #### Are you evaluating the low latency Ubuntu Linux kernel for your system? [Get in touch](https://ubuntu.com/internet-of-things/contact-us) ## Further reading Why is Linux the OS of choice for embedded systems? Find out with the ultimate [guide to Linux for embedded applications](https://ubuntu.com/engage/linux-embedded-applications-whitepaper). In [this exclusive webinar](https://ubuntu.com/engage/linux-embedded-applications-webinar), you will learn more about the embedded landscape, the IoT and how Ubuntu Core is raising the bar for embedded Linux. ## Sign up for our newsletter Get the latest Canonical news and updates in your inbox. Work email: \*I agree to receive information about Canonical's products and services. By submitting this form, I confirm that I have read and agree to [Canonical's Privacy Policy](https://canonical.com/legal/dataprivacy). Sign up ## Share on --- ## Related posts [### Arduino® VENTUNO™ Q is available for pre-order with Ubuntu pre-installed](https://canonical.com/blog/arduino-ventuno-q-is-available-for-pre-order-with-ubuntu-pre-installed) London, UK – August 25, 2026 – Following our initial collaboration announcement in March 2026, Canonical and Arduino (a subsidiary of Qualcomm Technologies, Inc.) are excited... [Canonical](https://canonical.com/blog/author/canonical) 25 August 2026 [### Advantech AOM-2721 is now Ubuntu Certified](https://canonical.com/blog/advantech-aom-2721-ubuntu-certified) Canonical announces that the Advantech AOM-2721 is officially joining the list of Ubuntu Certified Hardware. [Mikhail Khazov](https://canonical.com/blog/author/khazov-m) 13 August 2026 [### So you need to add microcontrollers to your fleet: now what?](https://canonical.com/blog/microcontrollers-ubuntu-core-golioth) Your Ubuntu Core fleet is running beautifully. OTA updates roll out in minutes. Every device is strictly confined, cryptographically attested, and carrying a 10 to 15 year long... [Jonathan Beri](https://canonical.com/blog/author/jmberi) 18 June 2026 [### A look into Ubuntu Core 26: Building a local AI inference appliance in a virtual machine](https://canonical.com/blog/ubuntu-core-26-ai-box) Welcome to this blog series which explores innovative uses of Ubuntu Core. Throughout this series, Canonical’s Engineers will show what you can build with this Core 26 release,... [Gabriel Aguiar Noury](https://canonical.com/blog/author/g-aguiar-noury) 16 June 2026