9 ms·
I get the sense that applications with true realtime requirements generally have hard enough requirements that they cannot allow even the remote possibility of
by binary132 3y ago
I get the sense that applications with true realtime requirements generally have hard enough requirements that they cannot allow even the remote possibility of failure. Think avionics, medical devices, automotive, military applications.
If you really need realtime, then you really need it and "close enough" doesn't really exist.
This is just my perception as an outsider though.
- calvinmorrison 3y agoIf you really need realtime, and you really actually need it, should you be using a system like Linux at all?
- refulgentis 3y ago...yes, after realtime support lands
- lumb63 3y agoA lot of realtime systems don’t have sufficient resources to run Linux. Their hardware is much less powerful than Linux requires. Even if a system can run (RT-)Linux, it doesn’t mean it’s suitable for real-time. Hardware for real-time projects needs much lower interrupt latency than a lot of hardware provides. Preemption isn’t the only thing necessary to support real-time requirements.
- skyde 3y agowhat kind of Hardware is considered to have "lower interrupt latency"? Is there some kind of Arduino board I could get that fit those lower interrupt latency required for real-time but still support things like Bluetooth?
- lumb63 3y agoTake a look at the Cortex R series. The Cortex M series still has lower interrupt latency than the A series, but lower processing power. I imagine for something like Bluetooth that an M is more than sufficient.
- refulgentis 3y agoSure but that was already mentioned before the comment I was replying to. Standard hardware not being great for realtime has nothing to do with hypothetical realtime Linux.
- rcxdude 3y agorealtime just means execution time is bounded. It doesn't necessarily mean the latency is low. Though, in this sense RT-linux should probably be mostly thought of as low-latency linux, and the improvement in realtime guarantees is mostly in reducing the amount of things that can cause you to miss a deadline as opposed to allowing you to guarantee any particular deadline, even a long one.
- tyingq 3y agoI'm guessing it's not that technical experts will be choosing this path, but rather companies. Once it's "good enough", and much easier to hire for, etc...you hire non-experts because it works most of the time. I'm not saying it's good, just that it's a somewhat likely outcome. And not for everything, just the places where they can get away with it.
- froh 3y agonah. when functional safety enters the room (as it does for hard real time) then engineers go to jail if they sign off something unsafe and people die because of that. since the challenger disaster there is an awareness that not listening to engineers can be expensive and cost lifes.
- deleted 3y ago[deleted]
- synergy20 3y agono you don't, you use a true RTOS instead. linux RTOS is at microseconds granularity but it still can not 100% guarantee it, anything in cache nature (L2 cache, TLB miss) are hard for hard real time. a dual kernel with xenomai could improve it, but it is not widely used somehow, only used in industrial controls I think. linux RT is great for audio, multimedia etc as well, where real-time is crucial, but not a MUST.
- froh 3y ago> anything in cache nature (L2 cache, TLB miss) are hard for hard real time yup that's why you'd pin the memory and the core for the critical task. which, alas, will affect performance of the other cores and all other tasks. and whoosh there goes the BOM... which again as we both probably are familiar with leads to the SoC designs with a real time core microcontroller and a HPC microprocessor on the same package. which leads to the question how to architect the combined system of real-time microcontroller and compute power but soft real time microprocessor such that the overall system remains sufficiently reliable... oh joy and fun!
- synergy20 3y agothat's indeed the trend, i.e. put a small RTOS core along with a normal CPU for non-real-time tasks, in the past it's done on two boards: one is a MCU another is a typical CPU, now it's one one, very important for where RTOS is a must, e.g. robotics. How the CPU and MCU communicate is a good question to tackle, typically chip vendors provide some solutions, I think OpenAMP is for this.
- snickerbockers 3y agoPretty sure most people who think they need a real-time thread actually don't tbh.
- rcxdude 3y agoreally depends on your paranoia level and the consequences for failure. soft to hard realtime is a bit of a spectrum in terms of how hard of a failure missing a deadline actually is, and therefore how much you try to verify that you will actually meet that deadline.
- eschneider 3y agoThe beauty of multicore/multi-cpu systems is that you can dedicate cores to running realtime OSs and leave the non-hard realtime stuff to an embedded linux on it's own core.
- snvzz 3y agoThis is why the distinction between soft and hard realtime exists. Linux-rt makes linux actually decent at soft realtime. PREEMPT_RT usually results on measured peak latency for realtime tasks (SCHED_RR/SCHED_FIFO) on the order of a few hundred usec. Standard Linux lets latency go to tens of milliseconds, easily verifiable by running cyclictest from rt-tests for a few hours while using the computer. Needless to say, this is unacceptable for many user cases, including pro audio, videoconference and even gaming. In contrast, AmigaOS's exec.library had no trouble yielding solid sub-millisecond behaviour in 1985, on a relatively slow 7MHz 68000. No amount of patching Linux can give you hard realtime, as it is about hard guarantees, backed up by proofs built from formal verification, which Linux is excluded from due to its sheer size. There's a few RTOSs that are formally verified, but I only know one that provides process isolation via the usual supervisor vs user CPU modes virtualization model: seL4.
- moffkalast 3y agoI feel like at this point we have enough cores (or will soon, anyway) that you could dedicate one entirely to one process and have it run realtime.
- KWxIUElW8Xt0tD9 3y agoThat's one way to run DPDK processes under LINUX -- you get the whole processor for doing whatever network processing you want to do -- no interruptions from anything.
- deleted 3y ago[deleted]
- cptaj 3y agoUnless its just music
- itishappy 3y agoIt may not be safety critical, but remember that people can and will purchase $14k power chords to (ostensibly) improve the experience of listening to "just music". https://www.audioadvice.com/audioquest-nrg-dragon-high-current-ac-power-cable https://www.audioadvice.com/audioquest-nrg-dragon-high-curre...
- binary132 3y agowhat if your analog sampler ruins the only good take you can get? What if it's recording a historically important speech? Starting to get philosophical here...
- duped 3y agoUnless that music is being played through a multi kW amplifier into a stadium and an xrun causes damage to the drivers and/or audience (although, they should have hearing protection anyway).
- beiller 3y agoYour talk of xrun is giving me anxiety. When I was younger I dreamed of having a linux audio effects stack with cheap hardware on stage and xruns brought my dreams crashing down.
- dripton 3y agoYou can divide realtime applications into safety-critical and non-safety-critical ones. For safety-critical apps, you're totally right. For non-critical apps, if it's late and therefore buggy once in a while, that sucks but nobody dies. Examples of the latter include audio and video playback and video games. Nobody wants pauses or glitches, but if you get one once in a while, nobody dies. So people deliver these on non-RT operating systems for cost reasons.
- binary132 3y agoThis kind of makes the same point I made though -- apps without hard realtime requirements aren't "really realtime" applications
- pluto_modadic 3y agoI sense that people will insist on their requirements being hard unnecessarily... and that the bug is the fault of it being on a near-realtime system instead of it being faulty even on a realtime one.
- duped 3y agoThe traditional language is "hard" vs "soft" realtime
- binary132 3y agoRTOS means hard realtime.
- tremon 3y agoNo -- soft realtime applications are things like video conferencing, where you care mostly about low latency in the audio/video stream but it's ok to drop the occasional frame. These are still realtime requirements, different from what your typical browser does (for example): who cares if a webpage is rendered in 100ms or 2s? Hard realtime is more like professional audio/video recording where you want hard guarantees that each captured frame is stored and processed within the alotted time.
- wongarsu 3y agoThere is some amount of realtime in factory control where infrequent misses will just increase your reject rate in QA.
- abe_m 3y agoHaving worked on a number of "real time" machine control applications: 1) There is always a possibility that something fails to run by its due date. Planes crash sometimes. Cars won't start some times. Factory machinery makes scrap parts sometimes. In a great many applications, missing a real time deadline results in degraded quality, not end of life, or regional catastrophy. The care that must be taken to lower the probability of failure needs to be in proportion to the consequence of the failure. Airplanes have redundant systems to reduce (but not eliminate) possibility of failure, while cars and trucks generally don't. 2) Even in properly working real time systems, there is a tolerance window on execution time. As machines change modes of operation, the amount of calculation effort to complete a cycle changes. If the machine is in a warm up phase, it may be doing minimal calculations, and the scan cycle is fast. Later it may be doing a quality control function that needs to do calculations on inputs from numerous sensors, and the scan cycle slows down. So long as the scan cycle doesn't exceed the limit for the process, the variation doesn't cause problems.
- mlsu 3y agoThat is true, but generally not acceptable to a regulating body for these critical applications. You would need to design and implement a validation test to prove timing in your system. Much easier to just use an RTOS and save the expensive testing.
- vlovich123 3y agoBut you still need to implement the validation test to prove that the RTOS has these requirements…
- mlsu 3y agoYou do not, if you use an RTOS that is already certified by the vendor. This saves not only a lot of time and effort for verification and validation, but also a lot of risk, since validation is unpredictable and extremely expensive. Therefore it'd be remarkable not to see a certified RTOS in such industries and applications where that validation is required, like aerospace or medical.
- ajross 3y ago> Think avionics, medical devices, automotive, military applications. FWIW by-device/by-transistor-count, the bulk of "hard realtime systems" with millisecond-scale latency requirements are just audio. The sexy stuff are all real applications too. But mostly we need this just so we don't hear pops and echos in our video calls.
- binary132 3y agoNobody thinks Teams is a realtime application
- ajross 3y agoNo[1], but the people writing the audio drivers and DSP firmware absolutely do. Kernel preemption isn't a feature for top-level apps. [1] Actually even that's wrong: for sure there are teams of people within MS (and Apple, and anyone else in this space) measuring latency behavior at the top-level app layer and doing tuning all the way through the stack. App latency excursions can impact streams too, though ideally you have some layer of insulation there.
- lmm 3y agoLike many binary distinctions, when you zoom in on the details hard-versus-soft realtime is really more of a spectrum. There's "people will die if it's late". "The line will have to stop for a day if it's late". "If it's late, it'll wreck the part currently being made". Etc. Even hard-realtime systems have a failure rate, in practice if not in theory - even a formally verified system might encounter a hardware bug. So it's always a case of tradeoffs between failure rate and other factors (like cost). If commodity operating systems can push their failure rate down a few orders of magnitude, that moves the needle, at least for some applications.