Real time Linux has one known issue remaining
1–10 of 26 posts
Re: Real time Linux has one known issue remaining
#2Will this eventually get merged into the main Linux branch?
Are there any downsides to using the real time kernel for more mainstream tasks?
Re: Real time Linux has one known issue remaining
#3Is this RTLinux [1] or Real-Time Linux [2] ?
[1] https://en.wikipedia.org/wiki/RTLinux
[2] https://en.wikipedia.org/wiki/Linux_Foundation#Real-Time_Lin...
Re: Real time Linux has one known issue remaining
#4Is this RTLinux [1] or Real-Time Linux [2] ? [1] https://en.wikipedia.org/wiki/RTLinux [2] https://en.wikipedia.org/wiki/Linux_Foundation#Real-Time_Lin...
The latter.
Re: Real time Linux has one known issue remaining
#5Re: Real time Linux has one known issue remaining
#6Will this eventually get merged into the main Linux branch? Are there any downsides to using the real time kernel for more mainstream tasks?
> Are there any downsides to using the real time kernel for more mainstream tasks?
Real-time kernels tend to sacrifice anything in order to minimize latency, for being better for use cases where lowest latency is needed. This usually means tradeoffs regarding throughput, power consumption, resource usage, reliability and more, in order to get the lowest possible latency.
In some cases you need really low latency, but in most day-to-day tasks I don't think you need it (disclaimer: I run linux-zen personally, mainly for minimizing audio latency when doing music with bunch of hardware + desktop PC).
> Will this eventually get merged into the main Linux branch?
I'm not too familiar with kernel development so someone else should give you a definitive answer, but considering the tradeoffs it's very unlikely.
Re: Real time Linux has one known issue remaining
#7Will this eventually get merged into the main Linux branch? Are there any downsides to using the real time kernel for more mainstream tasks?
> Are there any downsides to using the real time kernel for more mainstream tasks? Real-time kernels tend to sacrifice anything in order to minimize latency, for being better for use cases where lowest latency is needed. This usually means tradeoffs regarding throughput, power consumption, resource usage, reliability and more, in order to get the lowest possible latency. In some cases you need really low latency, but…
Do you have concrete examples of any of those things?
The only real tradeoff I am aware of is you sacrifice IO throughput so that the kernel can spread time related service tasks more fairly and userland process can interrupt the kernel. But, as modern Linux kernels work, it is not obvious you experience these throughput problems if you don't mark any tasks with realtime priority. You can still get low power consumption, low resource usage, high reliability, etc, with realtime requirements.
Re: Real time Linux has one known issue remaining
#8This headline makes no sense. This particular version has one known issue. Real Time Linux in general of course has a myriad of issues, not least the existence of hypervisors, management controllers and so on in a given piece of hardware that can cause interrupts outside of OS control and therefore unpredictable latency.
Re: Real time Linux has one known issue remaining
#9Will this eventually get merged into the main Linux branch? Are there any downsides to using the real time kernel for more mainstream tasks?
> Are there any downsides to using the real time kernel for more mainstream tasks? Real-time kernels tend to sacrifice anything in order to minimize latency, for being better for use cases where lowest latency is needed. This usually means tradeoffs regarding throughput, power consumption, resource usage, reliability and more, in order to get the lowest possible latency. In some cases you need really low latency, but…
> where lowest latency is needed
Not so sure it would even be "the lowest", rather than "low enough, stable and predictable", even if it's higher on average than optimal.
For example, comparing a hashtable lookup to a BST lookup (and ignoring the memory hierarchy for the sake of example), the former would be faster on average, but the latter would produce more predictable lookup times without hiccups.
Re: Real time Linux has one known issue remaining
#10Earlier quoted context omitted.
> Are there any downsides to using the real time kernel for more mainstream tasks? Real-time kernels tend to sacrifice anything in order to minimize latency, for being better for use cases where lowest latency is needed. This usually means tradeoffs regarding throughput, power consumption, resource usage, reliability and more, in order to get the lowest possible latency. In some cases you need really low latency, but…
Do you have concrete examples of any of those things? The only real tradeoff I am aware of is you sacrifice IO throughput so that the kernel can spread time related service tasks more fairly and userland process can interrupt the kernel. But, as modern Linux kernels work, it is not obvious you experience these throughput problems if you don't mark any tasks with realtime priority. You can still get low power consumpt…
The degree to which the OS deviates from the vanilla kernel behavior depends on the requirements of the processes being run in real-time.
For example, to run hard real-time, high frequency (>10 kHz) tasks with low latency and jitter, one needs to disable CPU frequency scaling (among other things) when compiling the kernel. The result is higher power consumption.