4 ms·
You can divide realtime applications into safety-critical and non-safety-critical ones. For safety-critical apps, you're totally right. For non-critical apps,
by dripton 3y ago
You 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.
- atq2119 3y ago> who cares if a webpage is rendered in 100ms or 2s? Do you really stand by the statement of this rhetorical question? Because if yes: this attitude is a big reason for why web apps are so unpleasant to work with compared to locally running applications. Depending on the application, even 16ms vs 32ms can make a big difference.
- tremon 3y agoYes I do, because I don't think the attitude is the reason, the choice of technology is the reason. If you want to control for UI latency, you don't use a generic kitchen-sink layout engine, you write a custom interface. You can't eat your cake and have it too, even though most web developers want to disagree.
- lll-o-lll 3y ago> You can divide realtime applications into safety-critical and non-safety-critical ones. No. This is a common misconception. The distinction between a hard realtime system and a soft realtime system is simply whether missing a timing deadline leads to a) failure of the system or b) degradation of the system (but the system continues to operate). Safety is not part of it. Interacting with the real physical world often imposes “hard realtime” constraints (think signal processing). Whether this has safety implications simply depends on the application.
- jancsika 3y agoYour division puts audio performance applications in a grey area. On the one hand they aren't safety critical. On the other, I can imagine someone getting chewed out or even fired for a pause or a glitch in a professional performance. Probably the same with live commercial video compositing.
- eschneider 3y agoAudio is definitely hard realtime. The slightest delays are VERY noticeable.
- jancsika 3y agoI mean, it should be. But there are plenty of performers who apparently rely on Linux boxes and gumption.