Hacker News Reader

Comment by Aaargh20318 | Hacker News Reader

Aaargh20318

What does this mean for the common user? Is this something you would only enable in very specific circumstances or can it also bring a more responsive system to the general public?

View on HN

My understanding is that real-time makes a system slower. To be real-time, you have to put a time allocation on everything. Each operation is allowed X budget, and will not deviate. This means if the best-case operation is fast, but the worst case is slow, the system has to always assume worst case.

It’s a classic latency-throughout trade off: smaller latency - lower throughout. Doing certain operations in bulk (like GC) increases latency, but is also more efficient and increases throughput.

>real-time makes a system slower.

linux-rt's PREEMPT_RT has a negligible impact. It is there, but it is negligible. It does, however, enable a lot of use cases where Linux fails otherwise, such as pro audio.

In modern usage, it even helps reduce input jitter with videogames and enable lower latency videoconference.

I am hopeful most distributions will turn it on by default, as it benefits most users, and causes negligible impact on throughput-centric workloads.

RT doesn't necessarily improve latency, it gives it a fixed upper bound for some operations. But the work needed to allow RT can definitely improve latency in the general case -- the example of avoiding synchronous printk() calls is a case in point. It should improve latency under load even when RT isn't even enabled.

I think I'm right in asserting that a fully-upstreamed RT kernel won't actually do anything different from a normal one unless you're actually running RT processes on it. The reason it's taken so long to upstream has been the trade-offs that have been needed to enable RT, and (per the article) there aren't many of those left.

If by "common" user you mean the desktop user, not much. But this is a huge deal for embedded devices like industrial control and communication equipment, as their devs will be able to use the latest mainline kernel if they need real-time scheduling.

As far as I can understand, this is for Linux becoming an option when you need an RTOS, so for critical things like aviation, medical devices, and other such systems. It doesn't do anything for the common user.

The Linux kernel, real-time or not, is simply too large and too complex to realistically certify for anything safety critical.

For the parts of such systems that you would need an RTOS for this isn't really a likely replacement because the OS is way too complex.

The sort of thing it could help with is servicing hardware that does run hard realtime. For example, you have an RTOS doing direct control of a robot or medical device or whatever, and you have a UI pendant or the like that a user is interacting with. If linux on that pendant can make some realtime latency guarantees, you may be able to simplify communication between the two without risking dropping bits on the floor.

Conversely, for the common user it could improve things like audio/video streaming, in theory but I haven't looked into details or how much trouble there is currently.

It depends on the field. I know of one robots control software company planning to switch to a RT Linux stack. Their current one is a *BSD derived rtos that runs, kid you not, alongside windows.

RT Linux might not pass on some certifications, but there’s likely many systems where it would be sufficient.

With robots a lot depends on the scope of movement and speed, and whether or not it interacts with environment/people. For some applications the controller is already dedicated hardware on the joint module anyway with some sophistication, connected to an CAN (or etherCAT) bus or something like that - so no OS is the tightest loop - I could see the high level control working on a RT linux or whatever if you wanted too, lots of tradeoffs. Mainly though it's the same argument, you probably don't want a complex OS involved in the lowest level/finest time tick updates. Hell some of the encoders are spewing enough data you probably end up with the first thing it hits being an ASIC anyway, then a MCU dealing with control updates/fusion etc., then a higher level system for planning.

the most common desktop end-user that might benefit from this is those doing audio work: latency and especially jitter can be quite a pain there.

It could allow very low latency audio (1-2 ms). Not a huge thing, but nice for some audio people.

s/nice/needed/g

Reply on news.ycombinator.com