4 ms·
This kind of makes the same point I made though -- apps without hard realtime requirements aren't "really realtime" applications
by binary132 3y ago
This 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.