Hacker News Reader

Comment by protoman3000 | Hacker News Reader

It’s a Linux distribution with real-time kernel.

Here’s a download link if anybody is interested:

https://github.com/elk-audio/elk-pi/releases

When I read things like this, I really wish BeOS, with its already pervasively multithreaded kernel, had won the audio OS wars. _Le sigh._

Does Haiku share these qualities?

Yes.

It's a bit weird but I have such a nostalgic connection to this very specific BeOS ability.

As a teenager I had heard about BeOS and I tried it out. I must have gotten it from a magazine's CD.

And by mistake, clicking around, I opened all of my mp3 collection's files at the same time. Each of the mp3s opened in their own little player window - and they all started playing at the same time, without the UI starting to lag at all.

It gave me an appreciation of what a computer can do

Not only because of that, being fully written in C++ and multimedia oriented, for me it had a feeling of second coming of Amiga.

Oh well.

So the real time kernel patches have been mainlined? How comprehensive are the real time features of Linux now?

Almost all of the original PREEMPT_RT patchset are mainlined now, but the features are not (all) enabled by default. Low latency will always present a tradeoff with bandwidth, and Linux is used for so many different purposes that one is not clearly more important than the other.

For more than 10 years, Linux with the PREEMPT_RT patch has been capable of more-or-less hard real time, with latencies in the 10's of usecs range. That can be thwarted, however, by a variety of hardware features (SMI being the worst offender, plus devices that hog the PCI bus for too long), so you are not guaranteed this performance just by running that kernel.

Dumb question inbound are those features boot/runtime toggable or compile time options?

Compile time.

>more-or-less hard real time

Also known as soft realtime.

For hard realtime, you need guarantees. Linux is too complex and cannot possibly offer them; this is the territory of formal proof, with complexity growing exponentially with code size.

Look at seL4 for hard realtime.

Even with the "guarantees" offered by e.g. seL4, you still need cooperating hardware. SMIs on most mobos cannot be masked, and can take an eternity to be handled by the BIOS.

Fortunately, for realtime audio, you don't need hard realtime unless you're very close to overloading the CPUs. Soft realtime (i.e. 99% of all interrupts handled within N usecs, 100% handled with N*2) is good enough.

Right. Also for hard realtime with 100% deadline guarantees (absence of soft and programming errors assumed, for a second) you would choose an appropriate CPU like the ARM Cortex-R series. You'd also take care of the peripherals, i.e. choose 801.2AS or even Flexray.

100% handled with N*2 would be hard realtime.

No. Soft real time can miss some real time deadline.

AFAIK Linux RT kernel is designed to hit every deadline, but they just cannot offer a formal proof.

So "more-or-less" hard real time.

One of the problems is that the Linux RT kernel doesn’t stop you from using/writing devices/drivers that break those guarantees systemwide, as I understand it.

What kernel can give such a guarantee?

One that has no such drivers? Which would then imply limited hardware support as the price for the guarantee, which is a trade-off a general purpose kernel like Linux isn't going to make.

A microkernel one, potentially at least.

A kernel alone on a random hardware platform can't, but a kernel and a hardware core that watchdogs and flips the bird at a rt-violating driver+device, sure (I've toyed with VxWorks on devices that work this way).

Usually when you're entering that realm of such requirements, you're rarely talking about off-the-shelf devices.

seL4[0]. I'm not aware of any other.

[0]: https://sel4.systems/

>AFAIK Linux RT kernel is designed to hit every deadline, but they just cannot offer a formal proof.

And that's why it is soft realtime. No guarantee, no hard realtime. It really is that simple.

Linux has the ability of entirely freeing a few CPU cores with isolcpus though, so that you can implement your own real-time loop on it

Sure. And you can also run an RTOS on a separate chip, elsewhere on the same PCB.

Linux is still Linux, and it is still fundamentally not capable of hard realtime.

If anyone wants to try the as-much-rt-as-possible build in a nice ready package, there's the Xanmod project https://xanmod.org/ which offers it precompiled with a few other tweaks. It's aimed at gamer crowd, but I had a really good experience using it with music processing.

The default xanmod kernel is still not using the PREEMPT_RT features. They do note that "Real-time Linux kernel (PREEMPT_RT) build available [5.10-rt]." and that's how you get "as much RT as possible". The features in the normal version of their kernel will improve the user experience of latency, but will not address "realtime" in the way that PREEMPT_RT does.

Correct, the 5.12 versions don't have the PREEMPT patches, you'll need the 5.10-rt version.

Elk is using Xenomai, it's not just PREEMPT_RT.

https://elk.audio/audio-latency-demystified-part-ii/

Is it possible to make a BSD kernel real-time. (No, IIRC.) I notice Elk uses Xenomai. NetBSD has a utility called schedctl that purports to control the scheduling of threads and processes. An example in the manpage describes running top(1) with "real-time priority". https://man/netbsd.org/schedctl.8

The ability to compile a (close to) real-time kernel seems to be one difference between Linux and BSD not often discussed.

FreeBSD includes a realtime scheduler priority class (round robin per priority level).

The approach of making general-purpose OS kernels realtime seems like hard work to me. Surely what we want is a realtime microkernel, on which the conventional operating system can run as a (large!) task. As long as there is a way for processes running under the kernel to start realtime tasks directly on the microkernel, you can support all your realtime use cases, without having to make the whole operating realtime.

what is a real time kernel vs a normal kernel? just "faster"?

'real time' generally means latency guarantees and trading some throughput for consistent low latency for interrupts and scheduling. So faster in some dimensions and slower in others.

The Arch Linux wiki has some description of their real time patches:

https://wiki.archlinux.org/title/Realtime_kernel_patchset

Arch wiki is an amazing source of practical information. It's like graybeard forums but distilled into a readable text. My last laptop ran Mint distro; whenever I searched around for HW issues it was always their wiki, fully stocked with useful info and steps how to fix stuff.

"graybeard forums" = ?

I'm referring to the usenet, mailing lists, various issue trackers and distro-specific forums were knowledgeable people diagnose and solve problems for others. The arch wiki has some of same diagnostics/troubleshooting content in more approachable format and kept up to date. Quite a few times it pointed me in right direction even if I don't use Arch.

ah so grey haired as in experienced people think John Maddog Hall. got it. thanks.

Yeah, I'm always amazed when I end up looking at the Arch wiki for a Debian issue, simply because the Arch wiki is more relevant and up to date.

wow thanks for calling that out. Just spent an hour browsing through it and was basically an Operating Systems refresher course. Great resource!

Often it's explicitly not faster— you intentionally do work in a more interruptible/resumable/chunked way even if it's less efficient to do it that way than to just block the system and do it all in one shot.

These kinds of tradeoffs don't make sense for a lot of common Linux workloads, which is why it isn't the default.

Yes, and: in return you get documented guarantees about how much time certain operations are allowed to take. As opposed to “We work hard to make it fast most of the time. But, no promises because sometimes stuff happens.”

Real time offers predictability. In some contexts being certain of a 3ms latency is better than going randomly from 1 to 4ms which could make the code faster on the average but with less predictable timings.

"More responsive," is the typical simplified description.

Reply on news.ycombinator.com