Linux has Real-Time now. What the fart does that actually mean?
Вставка
- Опубліковано 23 вер 2024
- 20 years in the making. But what does a Real-Time Linux Kernel mean for most of us? Let's talk about how PREEMPT_RT works, what caused it to take over 20 years to get into mainline Linux, and what it means for the average Linux user.
More from The Lunduke Journal: lunduke.com/
Real-Time is huge for processing live audio where minimum possible latency is desirable.
These patches decrease the highest latency peaks. Real-time != low latency
Drones.
Pretty much anything a drone is doing can be improved with a real-time kernel.
real-time = predictable, but maybe not fast.
idd , as a dj you dont wanna run into buffer underruns (wich are more likely to happen if you use 96khz samplerates - to reduce latency in the first place - and a 16 samples buffer ) if systemd-timers decide its time to start that btrfs maintenance task that you forgot to disable ) been using an rt-kernel and wine asio for that reason for a long time now allows me to play 96khz 16samples buffer using pipewire+wineasio and ableton in wine
Please DM me if you're looking for someone to talk to about RT-DSP for live audio...
This and the recent FreeCAD 1.0 announcement bode well for CNC tinkerers using Linux.
Yep, that was my first thought... CNC/3D printer controllers using an SOC with a full UI built in would be nice.
Now we only need GIMP 3.0 to launch to wrap up this year. With a proper 5% Linux market share :)
@@Winnetou17 You understand the actual market share is drastically under reported? And Windows market share is drastically over reported, which has the effect of further reducing the overall percentages for Linux?
Linux actually has desktop share on par with MacOS. The Year of Linux desktop came and went years ago.
Which flavors FreeCAD will run on?
@@justanothercomment416 Any sources on that ?
the final revisions to enable RT code after 30 years gold wrapped with a purple bow is the most bureaucratic thing I have seen in a long time, for some reason it reminds me of that futurerama quote "Don't quote regulation to me! I co-chaired the committee that reviewed the recommendation to revise the color of the book that regulation is in. We kept it gray."
It's unfortunate that bureaucracy slows things down so much. But without it, crazy radicals would constantly change things back and forth their own ways. I'd rather a bureaucracy if it's what it takes to have stability in matters that affect a large number of people. I wish the bureaus were entirely staffed with people who know the subjects they govern. And that we could have them with ability to ensure they work for the people, not selfish power mongering oligarchs.
Recognizing that PREEMPT_RT is mature enough to be included in the mainline is bureaucratic?
We'll be so screwed once Linus retires.
We might be better off, you never know
systemd will become the kernel
@@BillinSD is this a joke?
@@BillinSD 🤣🤣🤣
@@BillinSD Three letters just got aroused.
real time support will be a blessing for midi clocked applications
Just a reminder that OS using Linux with PREEMPT_RT is still *not* true RTOS.
As long as things keep improving, and if a 'micro controller' with Linux with PREEMPT_RT and busybox and your application are reliable then I'm all for it.
@@autohmaeMost of the time, it would be better to have a fully RT MCU controlling the hardware, and use a Linux board with a PREEMPT_RT kernel and a fast interface to the MCU as the control plane.
It’s the separation of concerns, as in other fields like dataflow, where you have your predictable, low latency data plane which is just a dumb worker, and the control plane which might have more long running and complicated tasks (branching) driving the decisions for the data plane.
RTAI is a lot closer to RTOS. Too bad they lack funding and developers.
@@LtdJorge I don't know much about Linus or computers, because I have a Macbook Pro and iPhone, all I know is that I prefer graphics over text (that's why I've never tried Linus). But what is the reason you call the workers dumb? Is it because they are doing manual labour instead of typing on a computer in an office? That is very narrow minded of you in that case, and you should reconsider saying things like that. Remember cooking food is a manual task, and that writing text or watching streaming on a computer will not produce any food - not even my iPhone can do that.
@@oonmm the term "dumb worker" in this sense refers to part of the software running on the computer. It's not referring to a person.
I remember when you had to build your own RT kernels for audio Linuxes back in the day.
I had a tradition when I was much younger. Every year on December 31st I did build my custom "slimmest" kernel build. On a 466MHz Celeron it was a real paint.
@@jdrabCrazy how now I sometimes rebuild my kernel multiple times in a row in less than 10 minutes, because I forgot to enable something and Portage is telling me it needs that for a package. 466MHz Celeron -> 3950x (not that new anymore)
Edit: I forgot, without LTO it would even take much less. Also, I never rebuild, I have a script that mrpropers, cleans and builds.
@@jdrab Had the exact same CPU, and an even more extreme habit of building kernels with every stable release.
How is it now? There is no need to compile a custom kernel anymore?
@@elpelicanojiji Well there started to appear distros like Ubuntu Studio and such which had RT kernels. I've had Mac for quite long now so I don't know the situation, but like the video says, RT is now part of the mainline kernel so I reckon you don't have to compile it yourself.
I was just about to "ackshually..." when you said "20 years ago". So yes, very momentous - i remember those realtime special kernel builds from 20 years ago.
Real time makes you not ingest data and digest data in chunks and choke. For Video processing and other places where "buffering" is disastrous (you thought it was bad watching ;) ) this is one helluva god thing for Linux. A person first looking into Linux for media like audio or video processing and design no longer has to be told to go straight into "how to recompile or change kernel" just in the very quick end to say "Windows and $500 bucks for this & That it has to be... ". This is a good thing.
I second the idea of having a scroll with the commits but also a ceremony for major merges.
This RT merge should become an official holiday for Linux devs.
Most of the benefits of the RT work are already applied in the regular kernel and this has been the case for a few years now. This is why Linux desktops running modern kernels are more responsive than ever. The battle for desktops is on improving the system scheduler to squeeze better user input responsiveness while remaining as fast as possible. 6.12 and beyond should see benefits regarding that.
Is there anywhere a writeup on how this is done practically? (An article in ACM Queue maybe)
@@SterileNeutrino I can't point you at anything specific, but the way X11 works makes it especially difficult. Wayland is likely to further improve things there.
battle for desktops is about hardware and software support
PREEMPT RT , "Real Time Patch" etc have always been misnomers. Linux is not a Real Time OS , with or wirhout the RT patch.
It should be called the "lower latency" patch or something like that. Linux will be better for multimedia streaming and responsive applications, but this does not really open the door for actual real time domain, where real time OSes dominate, in automotive, aviation, and other deeply embedded domains.
@@YellowCable Lower latency is the entire point of the preempt code. But Linux does in fact have an RT scheduler. Making it an RT kernel. One can split hairs on soft vs hard, but Linux is factually an RT kernel so long as it's appropriately compiled.
Preempt ==> low latency
Rt kernel will be optimized for response time over throughput.
Want high throughput kernel for servers.
Want rt kernel for, e.g., audio, etc.
Want a normal kernel for desktops
Best update since kernel 3.11 for workgroups.
Anyone else remember when "pre-emptive multitasking" was one of the huge buzzwords for Windows 95? (Win 3.1 was based on voluntary multitasking, meaning that it could ask nicely but it was ultimately up to the process to give back control of the CPU).
Linux, being awesome right out of the gate, had pre-emptive multitasking right out of the gate.
Unfortunately both Linux and Windows from that era were still susceptible to processes hogging the processor if they were running in kernelspace.
@@JPs-q1o I still remember when SMP was new to Linux and it had the Big Kernel Lock.
@@JPs-q1o I believe Windows 95 / 98 did NOT have pre-emptive multitasking. Windows NT did, but was often used only in business environments - (notably many games did not run on NT). It was Windows XP that merged those two projects, and brought pre-emptive multitasking to the masses.
Oh, actually, I suppose the innovation in NT and Windows XP was more about using an MMU that truly prevented processes from crashing the whole machine. Maybe 95 did in fact introduce preemption.
I would argue that real-time might be a huge difference for linux gaming.
One of the most long-standing issues is audio skips and stutters which are happening even when overall system have plenty of resources to run the game.
These are more related to pulse audio and related problems with Linux audio. The fairly recent move to Pipewire as the preferred audio subsystem will iron out a lot of these issues. For games, you can get away with latencies in the 50-100 ms range and no one will notice. For professional audio production, especially recording or creating music, you need sub 50ms reliability, and ideally lower than 20ms. It also has to be sample accurate at high sample rates.
@@Intermernet In my current experience pipewire does not fully resolve clicking and skips without asking it to be not nice.
I agree, that professional sound work has much higher requirement for latency and it is more important there, but it's still something that will be very noticeable for gamers.
There's been (terribly outdated) RTOS Linux forks for aeons
The first thing i thought of when i heard the news was audio production similar to the asio in Windows. Im glad that hunch was somewhat correct!
I have been using linuxcnc with real time kernels for my cnc router since 2011. One big hurdle to good performance is that the system management interface runs whenever it wants regardless of the operating system kernel leading to a lot of jitter in the timing of control loops. Apparently it is more important to check fan speeds than running my router. Solution is to disable acpi / smi.
The kernel scheduler is a rather complex thing (far beyond setting niceness values of processes), but it will allow you to manually override that sort of behavior even within the normal kernel.
@@mytech6779system management mode runs below the operating system and any hypervisors and has absolute control over the processor. You can't patch the code that it's running because it's signed in firmware and its segment of memory is very heavily protected against reading/writing from other processes.
@@arlobubble3748 I didn't realize the OP was referring to ring -1 .
Yeah, that is just the result of poor hardware for the task. aka non-RT hardware.
Though that level can still be altered it generally isn't worth the effort when the end result will still be mediocre in the best case.
@@mytech6779 I mean there may be instances where you could but it's not exactly realistic for hobbyist level stuff. Motherboard manufacturers have access to development kits that let them alter SMM code that used to be used for all sorts of things like USB keyboard support on old BIOS based systems, and I'm sure many more features even though it wasn't really made for that purpose. If you were a manufacturer making custom boards to run the x86 processor on you could probably pay for access to a development kit and modify it to suit your needs.
Yeah, one of these days maybe Oxide Computer Corp will save us from ACPI on the PC.
Realtime means that you can run very dangerous software that needs realtime reaction to inputs and predictable latency, like medical equipment, factory robots, self driving cars. But hardware that needs this uses other, smaller operating systems (RTOS), so I doubt the bloated Linux kernel will be used for that.
Been used for this stuff for ages.
Real time simply means guaranteed worst case latency. Many people believe it means fast. Real time usually means lower bandwidth in exchange for increased reliability to maintain the worst case latency.
Common example of where real time make sense is audio processing. Thus the birth of Jack audio server. Heck, I've even seen RT Linux used with CORBA for real time flight control avionics. As well as radar processing.
Real time doesn't have to mean embedded nor specifically embedded processors. It simply means one has a worst case latency requirement.
Pretty much agree with all of this, although in the embedded world, in many applications you don't even need an RTOS. Totally agree that Linux bloat in many embedded applications is a PITA, not least boot time, the energy required, and cost of hardware to support it.
I'll add one more factor... time deterministic behaviour means everything in low level high speed applications, such as motor control or power supply feedback loops.
@@justanothercomment416 if it has been used like this, do you know why there exists real time OS that are very expensive?
@@rezah336this is not my expertise however there are many safety regulations in industries like medical equipment or assembly line equipment etc. and thus certifications that you meet these safety requirements. So to make a device for these industries you must use a certified kernel that meets safety regulations and these certifications give those kernels high pricing.
@@rezah336 Sure. Liability. If your medical pump misses an interrupt which halts the pump, and creates an overdose, who pays for that? This is just one example.
QNX and VxWorks are very popular and their pricing reflects the reality of liabilities and support for their products. Not to mention, someone has to port to new hardware and new peripherals.
I've played with QNX. Thought it was pretty cool. Used VxWorks for P95 radio, including the entire init process. Something I did was used at NASA for rover testing. And I also do embedded development, in addition to some phone stuff on the application processor side.
The RT world heavily overlaps with the embedded world but it's not exclusively so. As nez rightly points out, many applications within the embedded world (most?) use no OS at all. Even still, for many non mission critical apps, there are many RTOS solutions available (example, FreeRTOS).
Cheap hardware (couple bucks) is available to play with much of this.
This will be most important for CNCLinux as it should help with stability. Thanks for sharing.
Maybe not games per se, but their physics engines or their collision detection might give this some use. Specially with faster action RPGs sword swinging games like the souls games where you literally only have a few frames to try your best at low latency detection of what enemies and the player are doing. It's so hit and miss that they have to resort to huge sausage capsule collider (and sphere colliders) for hitboxes to make it look good, and even then sometimes people rightly complain about dodgy hitboxes.
Really helpful for a low cost, single CPU panel with a high priority controller application but a lower priority UI.
Fun things are fun, but this was misleading. printk() was dear not just to Linus, but to all developers dealing with kernel crashes. To ensure that last debug messages and dumps appear on serial console or screen, it was given shortcuts to deal with logging directly, with minimal involvement of the rest of the system code (which might already be garbage or point to nowhere in case of memory corruption). Special case included bypassing the scheduler (because any context switch could be the last on a broken system). Because that parallel prioritisation system was not playing by the rules, calls to printk() in kernel code could take control of the system for unpredictable amount of time. Not that important on a general purpose system (for a code that doesn't interact with printk() and its special handling), but breaking all guarantees if you need predictable low latency.
Anyone else remember when "pre-emptive multitasking" was one of the huge buzzwords for Windows 95? (Win 3.1 was based on voluntary multitasking, meaning that it could ask nicely but it was ultimately up to the process to give back control of the CPU).
Linux, being awesome, had pre-emptive multitasking right out of the gate.
Unfortunately both Linux and Windows from that era were still susceptible to processes hogging the processor if they were running in kernelspace.
In business we were already on NT at that point. Windows 95 was a consumer space product.
Or you saturate the IO or Memory subsystem (Linux overcommits memory and swapping and the OOM going AMOK are horrible). And that's not impossible right now, not everyone has NVMe everywhere nor infinite memory.
@@kevinpaulus4483 Nor are they running an installation. Running a LiveCD/LiveUSB for 3 weeks to 3 months, depending on the activity, usually exposes this flaw in my experience. I thought I was the only one who noticed 😁
...and you aren't kidding about when they run AMOK! 🎯
@@GregoryAlbright-t3p My recollection is fuzzy but Windows NT at v3.1 at that time already had pre-emptive multitasking, correct?
@@JPs-q1o It is my understanding is that 3.5 was more or less a direct port of VMS with the windows 3.11 interface bolted on top.
LinuxCNC has been using the RT patch that existed for a long time
Now if Universal Audio will just give me some Linux drivers for my Apollo Twin...
Latency is actually quite relevant in gaming, in particular the delay from last input to the next frame flip with updates based on that input. Then, though, availability of variable refresh without excessive buffering is sufficient: Latency needs to be low, yes, but timing doesn't need to be evenly spaced humans are *very* bad at distinguishing 75fps from 74fps so it's no biggie if you're a bit late. Audio is of course also involved but we're quite tolerant of audio latency because sound is naturally slow so as long as you can fill that ring buffer you're generally fine. Haptics probably needs RT, but then it also needs 1000fps so that's a whole different kind of beast anyway.
Will be great for LinuxCNC which has required pre-empt RT for a long time but always suffered the need to carefully choose the distribution on which to install.
Linux has potential to go ballistic now 😅
Literally, it will be used in drones. It might already be.
It's scary that the absurd scenario of the self-driving logic running on the same computer as the AC and the onboard entertainment system, is actually a plausible thing...
Very well explained for someone like me that is new to RT 👍 Would love to have a video dedicated the history, theory and implementation if RT in different architectures (like VAX for ATC, etc) Maybe too much to ask for in one video 😀
RT and the OS cannot do miracles. It just promises lower latency. This basically just gives you *even higher priority* and ensures that the kernel itself will not itself run on that high priority and interfere with your stuff. But there is no way to prevent several tasks requesting RT priority and fighting for the CPU resources and exhausting the system.
Funnily enough, your self-driving example is actually quite close to reality: openpilot runs several processes on linux, some of them not being RT-critical (UI), others are. But I don't know if openpilot uses RT kernel etc.
I've ran the RT patch on systems before, but this will be nice not having to switch over to it every time.
Gaming is absolutely a relevant application. It will let you make a game that has no tearing or judders in animation, and consistent latency from user input to the results onscreen. Right now if you want that you have to brute force it with extremely high framerates.
RT on Linux isn't new. National Instruments has some equipment that uses a RT OS Linux distro (USRP)
The realtime patch has been available for anyone to put in the kernel when they want. And the people who need realtime already had the technical competence to do it.
pressing X to doubt
@@bullpup1337 What's this, the middle ages? You don't have to travel to a secret library to confirm what I said is true. Fucking idiocracy.
Not really, for the past at least 5 years all major distros have had a Preempt-RT kernel right in their package manager. I've been using Preempt-RT for like 10 years but I haven't patched one myself in at least 5.
It is not true that this means a reliable latency limit, because modern CPUs have a security kernel built in that can interrupt anything CPU is doing and cause unacceptable latency. I think this is not likely but it can happen.
This is why important realtime things are and will be done on specialty hardware. Which may use the Linux kernel. In that case it would be reliable.
You can run Linux on 'microcontrollers', my guess is those do the correct thing.
Low latency is not a given! You can even have more latency as the RTOS scheduler decides to give your process a lower precedence because other time critical processes are set to have a high time response.
The only thing RT guarantees is that specific task will start in a specific time frame. And if it will need to stop for example user input or data acquisition then it will do just that.
guys, tell me the latency or jitter that you get and how you achieve it
i get 40 micro seconds sample jitter with 'sudo chrt -f -p 99 PID'
standard xubuntu 18.04
I still don't understand: Does this generally allow for lower latency, or just for more relability in exceptional cases (like other programs running in the background trying to do something)?
Does that mean the real time mode does not need the real time version of the kernel any more.
Do you think a real-time linux (and some changes in other areas) might improve a desktop linux's responsiveness to mouse and keyboard when working under stress?
This will be great for dedicated audio and networking devices.
Lions have gotten 4ms audio latency forever but it's always been getting incrementally more reliable. It'll never be able to bit bang a servo, bit bang LED brightness, or run clockcycle accurate emulators from user space.
I believe QSC Q-SYS is built on a realtime variant of linux. It's pretty great but the prices are... well, they're great too, but a different kind of great :/
perhaps this will foment something great in a good way :D
So will this make Linux on par with VxWorks? And what is the difference between Windriver linux and the common kernel now then?
If someone can find that video of Linux Plumbers Conference Where the developers handle him the gold code changes? It would be funny to watch, could not find by searching it
cooool man , tnks for the update...
Oh right. FreeBSD has had this for… 10 years now? Good to Linux catching up! I wonder if Linux also fixed the CPU pinning issues that they’ve been having for 5 years now.
Well, now you have choices.
KVM/Qemu sucks but does FreeBSD's Beehive have something besides a virtual serial console for Virtual machines now ?
@@kevinpaulus4483 It has had a vnc graphical console for quite some time.
Let me know when BSD is useful for something other than a server or workstation
@@piked86 it already is? A number of companies use it for their embedded systems.
would this be good for minimal osu latency?
I've tried the RT version before for music production, in hopes of getting the lowest possible latency when record monitoring, but it never seemed to make much difference.
Used correctly with software designed to make use of it (e.g. Jack or PipeWire with Reaper or Ardour), it can reduce your minimum buffer/frame size without underruns, but you still have to select that smaller frame to get the benefit.
@@microcolonel Yea, I know. It's just my latency is already reported at
If only he had delivered the scroll on a pillow 😅
Anyway, no need to wait for a new machine. Just build an extra initramfs and pick it in GRUB and you're done 😁
if you have a gaming machine will this make the "boss key" more responsive
When I think Real time, I think 1/60th second (16.667 ms) and less the OS will interrupt to full fill a real time interrupt process. Video games are real time as one example; where there is a big deal about low input latency. Well I think it is a good option that mainline Linux has this.
For me with all my studio gear realtime matters. Latency is a killer.
Putting Bill Maher in the kernel seemed like a strange decision.
@BryanLunduke
You can eliminate audio stutter on your gaming machine. There you go.
We have been using patches to make Linux pre-emptive and real time for ages. I see some stupid comments below. Just listen to what the nice man in the video is saying. Linux RT is great for industrial applications like drives or PLC’s using communications like ProfiNet etc where you set up things to execute in determined time slots and communicate etc at set intervals. So like he says, not necessarily fast, but necessarily predictable. You don’t need that in general computing. But things like signal processing etc can do with it. And no, it’s not for safety applications. But it can be part of a safety type application. RTOS etc are for much simpler applications where you don’t need a full on operating system like Linux. So you code according to the need. Either bare bones, or some scheduling scheme, or RTOS etc, or a full on OS.
Just learned about types of programs in my advanced operating system class and its limitations with actual realtime programs. 😂 This is Co-incidence?
So basically zephyr comes to application processors also rather arm microcontrollers
rt patch was available for quite some time 🤷♂️
How would it effect the virtualization and kvm machines.
Which are the distros that feature it by default (i.e., without the need to recompile the kernel)?
It's hilarious that hard realtime used to be an easy thing 40 years ago (just write an interrupt handler!) and today it's the pinnacle of 20 years of R&D. I think we may have lost something along the way.
"just write an interrupt handler", and then good luck debugging your priority inversion. An event (or interrupt)-driven real-time was never easy. Only bare metal polling real-time is easy to reason about.
@@vitalyl1327 If your interrupt handler has tasks waiting on it, you deserve what you get. There's a right way and many wrong ways to do interrupt processing.
@@fnunez it is extremely hard to formally reason about interrupt handling. The right hard real-time is polling hard real-time. I worked in particle physics experiments, high-frequency trading (where an extra 50us latency spike could cost you millions), in industrial robotics. In all cases polling bare-metal was the most robust solution. Forget about interrupts, they were always a wrong idea.
I used RT Linux (RedHat with special RT kernel) several years ago as a Turbofan Test Engineer for Lockheed and Rolls-Royce at Stennis Space Center. It was for our main DAS system, where all (10,000+) recorded sensor and/or calculated parameter had to be synchronized in real-time, within a very small tolerance of time variation.
So, it's not "now", it has been for decades.
7:02 Was it already in a mainline Linux kernel?
11:44 He did say it existed for years.
Oh, yeah we're talking about censors here. I mean sensors without a microcontroller.
2019
Challenges Using Linux as a Real-Time Operating System
Michael M. Madden*
NASA Langley Research Center, Hampton, VA, 23681
Human-in-the-loop (HITL) simulation groups at NASA and the Air Force Research Lab
have been using Linux as a real-time operating system (RTOS) for over a decade. More
recently, SpaceX has revealed that it is using Linux as an RTOS for its Falcon launch vehicles
and Dragon capsules.
Why do we need this on mainline, when had specialty low latency or even RT kernels for years?
Does this mean im going to have a sound driver that wont break at random?
Interesting, I use arch and I think I use an RT kernel. What did they change about printk that allowed this to be mainline?
Wobbly-Windows gets top priority on my machine! 😉🐧❤
Most underrated comment on this video!
This is the result of Linus not giving enough context for the merge so people have to guess what he added.
Your explanation seems to beg one important question: What IS the maximum guaranteed latency for the RT Linux kernel? I assume it's dependent on the processor's clock speed, but if the key takeaway is that there is a known maximum latency, how is that calculated?
A companion page to a 2020 paper stated:
"The blocking (or interference-free latency in the paper) is defined in Lemma 7 as: LIF ≤ max(DST, DPOID) + DPAIE + DPSD"
@@XGD5layer Since you can't post links, can you give me the exact name of the paper? I have no idea what any of those acronyms are (or what Lemma 7 is for that matter), but I assume they are defined in the paper somewhere.
@@XGD5layer NVM, a quick Google search of that quote revealed the paper: "Demystifying the Real-Time Linux Scheduling Latency
"
I miss old Linus.
RISC-V is pronounced "risk-five". (Edit: Got it right the second time 👍)
For me realtime OS doesn't mean faster, just higher priority can starve out lower priorities, and that's what desktop OS trying to avoid.
Well no akshually.
A realtime kernel has nothing to with process priority levels and starving processes. You may be thinking of Windows' realtime priority class, which is its highest priority class, everything >= priority 16. The priority class is called realtime but Windows is not a realtime operating system.
A kernel, realtime or not, can perfectly well limit a high priority process so it doesn't starve lower priority processes, if it's made to.
@@xlerb1637 By definition, a higher priority task should starve lower priority tasks. That's why they are prioritized accordingly. If one shouldn't starve the other they should have the same priority.
Priorities basically says I want the higher priority to run even if a lower priority task wants to. That's why it's higher priority. It's more important it runs than the lower priority task.
@@justanothercomment416 Linux has built into it, I don't remember the details, the ability to limit CPU time to a high priority process so an out-of-control process doesn't kill the system.
Linus needs to get an apprentice asap...
how do you time any preempt a real time code, it would simply preempt the clock and run in 0 time.
Wow so it’s true real time. Too often, real time has just been used to mean ‘fast response’, which is not what it means. The classical real-time system is the industrial PLC, which can give a guaranteed maximum response time to react to control inputs.
Not sure I get what "now" means. PREEMPT_RT has existed for a pretty long time. I've used that on boxes for real-time audio processing.
So what part is new? Haven't followed what the news are.
PREEMPT_RT has been an out-of-tree patch set for a long time, it's now fully merged.
@@autohmae Ah I see, thanks. Hopefully this change will make it easier to officially release PREEMPT_RT kernels for SBCs like the RPi and similar, which is something that IMO was severely missing.
just my cents... linux didn't go faster but "snappier"?
Here I thought rt had been in the kernel already
If you ever set up a daw you've probably compiled a rt kernel before
Lots of parts had been merged over the years and as he mentioned in the video, some commercial distributions offered a version of their OS with a patched kernel.
Siewior, if he is Polish which I suspect he is it is pronounced shyeviour (the ś sound is not present in english anymore, should be pronounced more whistly than "sh") śye, as in "yeah", viour, as in "your". and the "w" sounds like "v", as in Viper.
I ask that on nearly every Linux OS update bullet point. "Updated librandompackage 4.20h to librandompackage 6.9n"... Okay, what the hell does that mean and why should users care?
It would be fun to now take bets which is the next working tech that is is put on the eternal aspirant chair for decades by the kernel time.... posix, rt, xen, ...
So does this mean there's no need to install low latency kernal in the future?
You are actually missing the point. A correctly designed system with PREEMPT_RT enabled would be able to accommodate all the tasks you gave examples of. It does not mean that steering clear of the deer would take priority over other tasks. It also does not mean extremely low latency. Tasks that need to run more often would typically preempt tasks that are run less often.
he said: not fast, but predictable multiple times in the video.
Imagine a Tesla running on Debian 😏👍
😈
Hi Brian, is this the same as the Realtime process priority in Windows?
Now, next thing on the list: getting Android fully merged.... please, please !
I think if it will unfortunately help HFT companies
Re: running Tesla on the same Linux computer, given Elon Musks love of cost cutting I wouldn't be surprised if the next Tesla refresh introduces a Linux powered Raspberry Pi 5 controlling all critical systems in the car... :)
Realtime kernel is well and good, but I think I would probably want the self-driving functionality running on a dedicated CPU rather than worrying about interrupting the audio process at all.
isnt a isolated cpu core enough?
@@rezah336 I don't know enough about silicon design to really trust that. Frankly I'm not sure whether something like self-driving even really belongs in an OS in the traditional sense.
@@rezah336 not always, there's also memory / system bus contention that can affect latency quite significantly. Not to mentioned shared L3 cache adding hard to calculate worst case memory latencies.
@@vitalyl1327 thanks for info
Linus stole my dog.
So it can behave RTOS?
I thought Ubuntu Studio had a real time kernel for quite some time for the sound apps.
It has, and will still be considered more "real-time" than what this kernel addition is doing in reality.
i wonder why linus didnt get inspiration from ucos which was already open source back then, 90's. its now a micrium company beings used by nasa critical systems and others.
the linuxcnc crowd has been kernel patching for a long time.
This is amazing
I standby that rt when used with screen refreshes, that it should lead to a better experince. More so with waylands defaults.
There is less benefit to have screen data that isn't the next frame for most interactive UIs, so you could have the the time hard synced with the screens choosen refresh rate instead and save the wasted cycles making frames that won't and/or shouldn't be sent to the display.
You should convince someone capable of doing so do perform a case control study (phoronix maybe but I doubt it).