4 ms·

I am confused by this. So is the problem that realtime 'should' just be used when there is a critical 'life threatening' problem if the deadline is not met, but

I am confused by this. So is the problem that realtime 'should' just be used when there is a critical 'life threatening' problem if the deadline is not met, but to use realtime for a system that is not critical is seen as wrong? Lets say you have an algo controlling a fighter jet. That is realtime. If you had exactly the same algo in a 3d fighter pilot game. That should not be called realtime? Is this just an ego thing?

jacquesm 11y ago
No, it's a guarantees thing. If you can't guarantee your latency and scheduling then you're not real-time. So if you're doing something that you run on a jet that needs to be updated 5000 times per second +- 10us otherwise something breaks or the plane becomes uncontrollable then that's real-time. If it's a game version of the same you don't care about those guarantees because nothing would actually cause the plane to crash. Of course controlling the plane itself may not have such tight loops but plenty of processes active in the flying plane may very well have extremely tight constraints (for instance: engine management, especially near maximum power output). In real life there would be a penalty for missing an interrupt or a scheduled deadline, in a simulation everything would just happily hum along with a tiny delay. If you were simulating the real plane then you'd want your simulation to halt at that point so that you could figure out exactly what went wrong. One piece of hardware in our offices in Amsterdam long ago had a 'lost data' led latched so it would stay on if a fault condition ever happened no matter how briefly, if that led ever came on it meant going back to the drawing board because it indicated we were not in control of the machine to the extent that we thought we were.
- eric-hu 11y ago
  > If it's a game version of the same you don't care about those guarantees because nothing would actually cause the plane to crash. > If you were simulating the real plane then you'd want your simulation to halt at that point so that you could figure out exactly what went wrong. Doesn't this all depend on the point of the simulation? For instance, the simulation could be an integration test of flight control systems. In which case, yes, you'd want the simulation to halt for debugging, as you stated. On the other hand, if the simulation is a networked flight sim trainer for pilots, then you would benefit from having the simulation do exactly what a plane would do in the real world. I think there's some insight in the OP's article, but I think he goes a bit too far. To me, "real time" has a domain specific meaning: there's a greater importance placed on time for this thing over that. That's a legitimate use of the word _in that domain_. If the world we we're living in were actually the Matrix, our use of "real time" wouldn't be less legitimate just because a plane crash is now bits changing instead of an actual plane crash.

jacquesm 11y ago

No, it's a guarantees thing. If you can't guarantee your latency and scheduling then you're not real-time. So if you're doing something that you run on a jet that needs to be updated 5000 times per second +- 10us otherwise something breaks or the plane becomes uncontrollable then that's real-time. If it's a game version of the same you don't care about those guarantees because nothing would actually cause the plane to crash. Of course controlling the plane itself may not have such tight loops but plenty of processes active in the flying plane may very well have extremely tight constraints (for instance: engine management, especially near maximum power output). In real life there would be a penalty for missing an interrupt or a scheduled deadline, in a simulation everything would just happily hum along with a tiny delay. If you were simulating the real plane then you'd want your simulation to halt at that point so that you could figure out exactly what went wrong. One piece of hardware in our offices in Amsterdam long ago had a 'lost data' led latched so it would stay on if a fault condition ever happened no matter how briefly, if that led ever came on it meant going back to the drawing board because it indicated we were not in control of the machine to the extent that we thought we were.

eric-hu 11y ago
> If it's a game version of the same you don't care about those guarantees because nothing would actually cause the plane to crash. > If you were simulating the real plane then you'd want your simulation to halt at that point so that you could figure out exactly what went wrong. Doesn't this all depend on the point of the simulation? For instance, the simulation could be an integration test of flight control systems. In which case, yes, you'd want the simulation to halt for debugging, as you stated. On the other hand, if the simulation is a networked flight sim trainer for pilots, then you would benefit from having the simulation do exactly what a plane would do in the real world. I think there's some insight in the OP's article, but I think he goes a bit too far. To me, "real time" has a domain specific meaning: there's a greater importance placed on time for this thing over that. That's a legitimate use of the word _in that domain_. If the world we we're living in were actually the Matrix, our use of "real time" wouldn't be less legitimate just because a plane crash is now bits changing instead of an actual plane crash.