[pwnna]

I found this to be hard-ish to get started as well. However, it turns out you just need to write your program to be performant, and know a few tricks to tune the OS and the scheduler. After looking on the internet and failing to find material about this, I wrote a series of blog post for this topic recently, starting with this post: https://shuhaowu.com/blog/2022/01-linux-rt-appdev-part1.html

The series is mostly complete, except one to two posts on more advanced topics like validation and lockless programming.

[skyde]

Real-time software does not mean fast software! It mean determinism, guarantee that each time it run it will never take more than x milliseconds to complete. Those guarantee are very hard when considering a system like linux with many background process or thread each randomly doing IO and allocating memory.

[karmakaze]

That depends on whether we're talking about hard-realtime or soft-realtime.

[0] https://www.google.com/search?q=hard-realtime+soft-realtime

> A hard-real time system is a system in which a failure to meet even a single deadline may lead to complete or appalling system failure. A soft real-time system is a system in which one or more failures to meet the deadline are not considered complete system failure, but that performance is considered to be degraded.

[skyde]

even in the case of soft-realtime we don't say the system is real-time because it's fast. We say its realtime because majority of the time it meet its deadline.

[karmakaze]

Yes, at the same time I don't know if I'd characterize a soft-realtime system as slow. One way to meet deadlines is by being very efficient/fast, while keeping variance low (e.g. no stop the world gc).

[netr0ute]

By that definition, a phone call that always takes 10 seconds for one side to hear the other is realtime.

[AlotOfReading]

That would indeed be a realtime system by common definitions as long as that latency is guaranteed. Audio and video are commonly considered soft-realtime domains for exactly that reason.

[unsafecast]

Yep. If you mean low-latency, say that. Real-time is an unfortunate name, but it means what it means.

[numpad0]

And phone … callthatju arousmpnnd is n’t realtime.

Technically not relevant but I know that a lot of early handhelds that repurposed RTOS for GUI felt slow, jumpy and unresponsive, perhaps because everything was polled? In that sense RTOS can be slow.

[jcelerier]

Who's that "we" ? For anyone I've worked with, real-time also implied "reaction time is faster than human perception"

[pwnna]

You're right, but I think it's mostly semantic and depends on how you define "performant" or "fast". Real-time software is about being "fast enough", every time. After all, slow and fast is subjective measures that varies wildly depending on the context.

In the context I'm working with (1000Hz hard real-time), the software has to be "performant" (running algorithms like collision detection) in a deterministic manner as each loop iterate has less than 800us of time. When developing such a system, the developer needs to accurately know the performance characteristic of the software ahead of time.

In another system, fast might mean 5ms, which is unacceptably slow in the context above.