Real-time Ubuntu is now generally available
ubuntu.com
ubuntu.com
What are the disadvantages of a real time system?
I mean, real time sounds better than not real time, so why not include it into the standard Ubuntu distribution.
You'll want to use a low-latency system for multimedia applications, games and other interactive systems. You want to use a real-time system when exceeding deadlines is cost-prohibitive or dangerous (below mentioned CNC machines, robotics, etc.). You will want to use a system which prioritizes throughput in all other cases.
Now consider that with 3 of the processes being idle, and 1 trying to do as much computation as possible; it's obviously wasteful.
Trying to be more efficient, while still remaining real time, gets progressively more complicated.
Freertos even has SMP on the RP2040 dual core system.
"Low" is in the eye of the beholder. The key word is never.
I'm building a custom kernel for the Odroid N2+ as I write this. I can't wait to not do this again.
> Ubuntu Server 22.04 LTS with the real-time kernel is available via Ubuntu Pro
They need to kill this Ubuntu Pro garbage post haste before the entire OSS community turns on them. Charge for the support, not the software.
If Ubuntu pro gets big enough, we might actually see a rocky-style Ubuntu pro clone.
Everyone has different opinions, but I've derived quite a bit of value from Canonical's F/OSS efforts/contributions and am supportive of them exploring ways to make money, even if it's for a period of time, behind high-value-add features.
Not everyone on the OSS community can afford to be street performers living from tips.
I would have thought that givig the audio process full priority would have the greatest benefit.
I think you're conflating two separate things. Giving full priority to an audio processing thread will ensure it will be scheduled as much as possible which increases throughput. This is crucial for things like rendering (audio or video) where the process takes in the order of minutes or hours and needs to be completed as fast possible.
In the other application, such as synthesizers, virtual instruments (MIDI keyboard -> MIDI signal -> DAW -> sound wave), music notation etc you care only about latency. Human brain is hard-wired to observe even the minutest latency in music, especially in bass register, any millisecond delay will be perceptible to highly trained professional musicians. To fix this, you need to tell kernel, when it receives a signal, the thread cannot be scheduled out. Here, you don't care about throughput, but have extreme latency requirements.
I, as a hobbyist composer, personally use a traditional archlinux setup for my studio. It's not real time at all. It honestly sucks, the latency is extremely noticable, which makes some applications, such as playing on my keyboard and hearing soundfonts through DAW impossible; as the latency makes me confused and prevents me from playing the keyboard properly. This is ok for me, as it doesn't distrupt my personal workflow (I have a very slow, calculated approach to composing, and when I need to improvise, I do it on my piano) so I didn't care about optimizing it. But if you're a professional musician and need good latency, something like this is can be crucial.
I want to give my DAW full priority and let it handle the scheduling. I want any other process on my operating system to take a backseat.
Note, audio is about latency. Other real time applications need much more CPU power, but they can accept more jitter and latency.
Anecdotally that's one of the "eureka" moments behind SpaceX's industry-disrupting low production costs. They realized they only really needed ±20ms precision for communication between different sensors/actuators, which made heavily multiplexed ethernet busses feasible, and got rid of massive amounts of dedicated serial lines and related hardware.
13 years later, competitors are just about ready to catch up.
I want my audio processes to have full priority over any other task on my OS. I don't mind if my DAW increases the latency of other processes running on my PC.
Time-resolution for midi-input is not high enough for it to matter; it will be quantized to midi-time anyway.
It is critical for audio-effects and synthesizers that are taking live input and emitting live output. These exist, but I'm not sure they are commonly used on linux or if it's wise running with low resources.
I don't understand this perspective. I've seen musicians at all levels use all sorts of crazy instruments. The output of live audio processing may not be used in the final result, but it's very important for capturing a performance.
> not sure they are commonly used on linux or if it's wise running with low resources
Linux-based studios are the norm for many hobbyists and in educational settings where the goal is actually teaching and not just indoctrinating a new cohort of commercial software users. Also, who said anything about "low resources" and what does that even mean?
I don't think so. And what does that even mean?
There are some hobbyists using Linux for music production. But it's so far behind MacOS and Windows in that regards, that no sane person would use it for any other reason than prefering free software or using some esoteric piece of software that's only available on Linux.
I wish it was different, because than I could ditch Windows and move to Linux full stop.
Sound travels about 2m in 6ms. Iirc, it's difficult for humans to perceive time differences smaller than 20ms, so humans perceive sounds from within a radius of 6m simultaneously.
When playing an instrument, I can live with a 20ms roundtrip.
I don't care about playback performance. I usually have my playback buffers at 512 samples, but I could easily deal with 1024 samples.
It's not really a matter of how many resources a system has, without proper realtime scheduling a thread might still be randomly delayed for just a few milliseconds too many due to scheduling screwups.
I don't want the OS to take away resources from my DAW at any point in time, exactly for the reason to avoid dropouts.
For real-time performance, yes; but that doesn't represent the whole, or even the majority, of audio work.
Presumably this means one could run LinuxCNC.
(though AFAICT, most folks as using Grbl on an Arduino these days).
Some Rockwell (Allen-Bradley) PLCs, for example, now use commodity Intel hardware like i7 processors and Ethernet modules. These PLCs and I/O modules also provide deterministic time guarantees, especially important for motion applications. Since the OEM has control of the hardware, the software is tightly coupled to ensure deterministic performance.
However, I think its still a little while away from being fully mainlined. The last I remember were issues with preemption in printk calls. Adding this level of preemption support to every subsystem is extremely difficult. Though, I must say that the patched kernels function pretty well. If you need proper real-time, ditch GNU/Linux and go with a real real-time kernel like QNX, VxWorks, etc. Linux will never be true real-time and that's an acknowkedged fact
It is described as: "This kernel includes the PREEMPT_RT realtime patch set."
So I take it it's still a patch not part of mainline yet?
Out of curiosity I tried it:
https://packages.debian.org/bullseye/linux-image-5.10.0-20-r...
... but only to be met with NVidia drivers telling me they cannot patch real-time kernels!
Didn't look more into it: it's maybe easy to solve.
For example, music production is low bandwidth (meaning that not a lot of data goes in each individual action) but it has a lot of signals that when not processed immediately, things will sound off. Same for a space rocket, small packets of data stream from one subsystem to another and things can go bad if the data gets delayed, but each data packet does not requires huge amounts of processing, they just need to be processed ASAP. Both of these benefit from a real time system.
On the other hand, when you are doing something like graphical rendering, heavy data processing like training machine learning models, mining crypto, simulations and other types of processes that require a lot of data to be processed in one go and don't really mind if the data gets processed now or 1ms later, then you're better off with a non real-time system. Because if you had a real-time system for these tasks, you could actually see lower total performance for each marco task. Applications would be very snappy on your desktop, but you'd have to wait a bit longer for things to load fully in a real time system that does medium to high data processing.
Games are a mix of both maybe, real-time for input processing and sound, non real-time for graphical rendering (if you don't need extremely consistent framer ates in the realms of <1% deviation or something). With in game physics simulation being a mix of both.
Is that a fair summary?
But then there's low latency systems? Which I don't really know the difference compared to a real-time system, that should offer low latency by default because it tries to process as many signals as they come in.
As for gaming I am really interested if there are benefits to real time kernels and whether if its possible to make a hybrid kernel that turn to real-time only when needed.
I really really doubt this is actually real time in the sense that even remotely useful sort of worst case timing could be determined.
https://en.wikipedia.org/wiki/Real-time_computing
Its important, as it allows to use run of the mill operation systems and programs, while still have reliable sheduling.
If you make a car for example, that shares its ECU with various systems, some of the time critical, the whole affair needs to have the ability to schedule reliable, as to meed the dead lines. This is not doable with a run of the mill os.
Thus there are special operating systems that provide realtime capability - e.g.
https://roscon.ros.org/2015/presentations/RealtimeROS2.pdf
https://en.wikipedia.org/wiki/ECos but are usually not posix systems and generally incompabtile to them. Also normally they cost a arm and a leg to license.
And now ubuntu can run on car-hardware with time critical software running on it.
What is the latency and timing jitter with ubuntu real time for a user land process? a kernel module? Are there any guarantees?
On a cortex-m there are very clear ideas of what interrupt to isr latency is going to look like, and while not easy its possible to determine bounds of timing.
On a linux x86 machine with god knows what running? Yeah...
Generally the way Linux RT projects solve that is by scheduling the CPU between the realtime processes and "the rest of Linux", where the rest of Linux acts as a single low-priority best-effort process. How much work that one part is doing within isn't really relevant.
Typically, the realtime processes can only communicate with "the rest" by some very limited channel, e.g. message-passing, so they're never hampered by kernel locks or such.
As far as I've read, consumer variants of x86 CPUs themselves are not ever capable of hard real time, there's "management" stuff that'll just decide to pause the CPU sometimes.
It isn't very unclear imho. And it's not like prempt_rt is some new thing, it is pretty well understood in the industry
E.g. I need to run a task at exactly every 100us, or within 10us of a gpio event, or ...
You get the idea. Linux RT is, in my mind, abusing a term to market itself better. There's absolutely zero guarantees of not having your process indefinitely delayed.
It's less likely, but zero guarantees and no possibility of doing any sort of worst case determination. That's not "Real Time" that's just better scheduling.
Linux RT is basically just the preempt_rt patches.
In the normal linux kernel side, many (all?) kthreads can't be interrupted. This prevents the kernel from handling the interrupts from io in a bound time since it has to wait for a kthread to yield. The preempt_rt patches enable preempting kthreads.
> E.g. I need to run a task at exactly every 100us, or within 10us of a gpio event, or ...
Allowing preempting kthreads enables the kernel scheduler to run more deterministically and not be blocked by kthreads doing things. This allows the kernel to ensure a gpio task gets serviced by a given deadline.
There's still spinlocks and critical sections which can block preemption, but they're minimized.
Linux rt provides a "execute my thread by a deadline option".
> It's less likely, but zero guarantees and no possibility of doing any sort of worst case determination. That's not "Real Time" that's just better scheduling.
Hate to tell you, but thats every RTOS. The only one I know of that has a provable bounded scheduler is SeL4. IMHO, thats cool.
But FreeRTOS, Zephyr? Nope same thing the Linux preempt_rt patches do. Now its smaller and easier to ensure the system isn't overloaded, less kthreads to review for critical sections, etc.
If you just write something it does not qualify as "truth" just because it is written by you, you know?
They even invented a feature that can be used in every web browser today - it is called "URL" and is used to help you give users a quick method to read the "source of truth" that your words are based on.
Just use it and your words will have more power - it is like magic!