3 ms·

Realtime is usefull for robotics, industrial automation and other time critical applications. https://en.wikipedia.org/wiki/Real-time_computing https://en.wiki

Realtime is usefull for robotics, industrial automation and other time critical applications. https://en.wikipedia.org/wiki/Real-time_computing https://en.wikipedia.org/wiki/Real-time_computing Its important, as it allows to use run of the mill operation systems and programs, while still have reliable sheduling. If you make a car for example, that shares its ECU with various systems, some of the time critical, the whole affair needs to have the ability to schedule reliable, as to meed the dead lines. This is not doable with a run of the mill os. Thus there are special operating systems that provide realtime capability - e.g. https://roscon.ros.org/2015/presentations/RealtimeROS2.pdf https://roscon.ros.org/2015/presentations/RealtimeROS2.pdf https://en.wikipedia.org/wiki/ECos https://en.wikipedia.org/wiki/ECos but are usually not posix systems and generally incompabtile to them. Also normally they cost a arm and a leg to license. And now ubuntu can run on car-hardware with time critical software running on it.

bfrog 4y ago
Oh I'm well aware of what is generally meant by real time. It's also abused as a marketing term to the point where it loses some meaning. What is the latency and timing jitter with ubuntu real time for a user land process? a kernel module? Are there any guarantees? On a cortex-m there are very clear ideas of what interrupt to isr latency is going to look like, and while not easy its possible to determine bounds of timing. On a linux x86 machine with god knows what running? Yeah...
- qikInNdOutReply 4y ago
  I guess there is a almighty scheduler in the kernel, which at any given moment is allowed to send your processes to sleep, pushing all the registers on some stack, plus execution pointer and do something else. Its certainly not by software yielding.
- yencabulator 4y ago
  > On a linux x86 machine with god knows what running? Yeah... Generally the way Linux RT projects solve that is by scheduling the CPU between the realtime processes and "the rest of Linux", where the rest of Linux acts as a single low-priority best-effort process. How much work that one part is doing within isn't really relevant. Typically, the realtime processes can only communicate with "the rest" by some very limited channel, e.g. message-passing, so they're never hampered by kernel locks or such.

bfrog 4y ago

Oh I'm well aware of what is generally meant by real time. It's also abused as a marketing term to the point where it loses some meaning. What is the latency and timing jitter with ubuntu real time for a user land process? a kernel module? Are there any guarantees? On a cortex-m there are very clear ideas of what interrupt to isr latency is going to look like, and while not easy its possible to determine bounds of timing. On a linux x86 machine with god knows what running? Yeah...

qikInNdOutReply 4y ago
I guess there is a almighty scheduler in the kernel, which at any given moment is allowed to send your processes to sleep, pushing all the registers on some stack, plus execution pointer and do something else. Its certainly not by software yielding.
yencabulator 4y ago
> On a linux x86 machine with god knows what running? Yeah... Generally the way Linux RT projects solve that is by scheduling the CPU between the realtime processes and "the rest of Linux", where the rest of Linux acts as a single low-priority best-effort process. How much work that one part is doing within isn't really relevant. Typically, the realtime processes can only communicate with "the rest" by some very limited channel, e.g. message-passing, so they're never hampered by kernel locks or such.