The future of realtime Linux in doubt
The future of realtime Linux in doubt
Posted Jul 11, 2014 9:15 UTC (Fri) by marcH (subscriber, #57642)In reply to: The future of realtime Linux in doubt by nevets
Parent article: The future of realtime Linux in doubt
The problem with any big and complex system is that you cannot reason and make proofs about it. One example is memory management: since it's shared across the whole system you can never predict how long it will take since it depends on too many other things.
So, again as an example, would you qualify as a "bug" an involvement (direct OR indirect) of the memory manager in your real-time thread(s)?
Now more general questions about the -rt branch (pardon my ignorance): is it possible to use -rt to implement something which is both "hard" real-time and non trivial and that does involve neither any memory management nor any other unpredictable part of the kernel? Or are people using the -rt branch just because it gives typically lower latencies?
Posted Jul 11, 2014 9:30 UTC (Fri)
by dlang (guest, #313)
[Link]
remember that "hard real time" only means that you meet your stated target. defining that you get the result of 1+1 within 1 second could be a "hard real time" target
more specifically, burning a optical disk is a 'hard real-time' task, if you let the buffer empty out the resulting disk is trash, but Linux has been successfully burning CDs since burners were first available. Back at the start it wasn't uncommon to have a buffer under-run, but it's become almost unheard of in recent years (unless you have a _really_ heavily loaded system)
That said, and answering what you were really asking :-)
anything you do with linux will involve memory management and "unpredictable" parts of the kernel.
The way that -rt addresses this is to work to "guarantee" that none of these parts will stop other things from progressing for "too long". Frequently this is done in ways that allow for more even progress between tasks, but lower overall throughput.
There isn't any academic measurement of the latency guarantees that Linux can provide (stock or with -rt), it all boils down to people doing extensive stress tests (frequently with a specific set of hardware) and determining if the result if fast enough for them.
As noted elsewhere in this topic, stock Linux is good enough for many "hard real-time" tasks, the -rt patches further reduce the max latency, making the result usable for more tasks.
many people use -rt because they think it's faster, even though the system throughput is actually lower, but there are people who use it for serious purposes.
The LinuxCNC project suggests using -rt and when driving machinery many people report substantially better results when using -rt
Posted Jul 12, 2014 11:27 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
The problem with any system that you CAN reason and make proofs about it, is that those proofs have nothing whatsoever to do with the real world.
"As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality." Albert Einstein.
Cheers,
Posted Jul 15, 2014 21:10 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
Yes we all know that 2 + 2 is actually 5 in the "real world".
> "As far as the laws of mathematics refer to reality, they are not certain;"
... while "not certain" actually means "nothing whatsover to do" in the same real world.
The future of realtime Linux in doubt
The future of realtime Linux in doubt
Wol
The future of realtime Linux in doubt