I have been asked this question: “Do you think the system will need deterministic time or real time responses?” The problem I have is distinguishing the difference between the two. I know that a real time response will respond to an input within a specific time period but I not sure what a deterministic response will do? Thanks.
-
\$\begingroup\$ Not definitive, but this may help \$\endgroup\$– MarlaCommented Dec 18, 2015 at 17:03
-
\$\begingroup\$ I don't understand what you mean by "The problem I have is disguising the difference between the two." Are you trying to set an exam question, but write it so that the answer is not obvious, or something else? \$\endgroup\$– gbulmerCommented Dec 18, 2015 at 17:13
-
\$\begingroup\$ Sorry I spelled it wrong. It was meant to say "distinguishing" not "disguising" \$\endgroup\$– user3178205Commented Dec 18, 2015 at 17:19
-
\$\begingroup\$ @Marla I have already read that article and I still can't seen to find what a deterministic response is \$\endgroup\$– user3178205Commented Dec 18, 2015 at 17:21
-
3\$\begingroup\$ Are you sure that question is an either-or question? I tend to think those phrases are two different ways of saying the same thing, which makes it a yes-or-no question. \$\endgroup\$– kkramboCommented Dec 18, 2015 at 17:53
4 Answers
A real time system has a constraint set as: the system should respond to an event within 10ms. Or: the system should run PID loop control at a fixed rate of 10kHz. Implicitly a period time of 100us is used.
Both are well set maximum time limits. However they are not exactly deterministic; one PID loop update may take 10us, while the next may take 15us. It also does not say about the passed time between updates; e.g. the "phase".
This "jitter" can be a problem in some systems. Deterministic describes that the "noise" is very low; i.e. it is very predictable how long an algorithm will run, it will not vary a lot (or it can be determined and compensated for) given varying inputs or states of the program.
Deterministic can be important while producing timed signals for example video. In that case you want to know exactly how long (intermediate) operations take to complete, even when the algorithm needs to take branches that take less or more time to execute.
Some high performance systems are challenging as they are "accelerated" CPU's that incorporate instruction pipelines and caches that may stall code execution in some conditions. Predicting/determining these conditions may be nearly impossible, which is why deterministic is very hard on complex platforms.
-
2\$\begingroup\$ Non-determinism can also provide side-channel information (which may be undesirable). \$\endgroup\$– user15426Commented Dec 18, 2015 at 19:53
I don't take credit for this answer at all, I happened to find it on Stack Overflow and I feel it does a really good job on summing up the difference between the two so if it works for you, please follow the link and upvote that answer.
You need to distinguish between:
- Hard realtime: there is an absolute limit on response time that must not be breached (counts as a failure) - e.g. this is appropriate for example when you are controlling robotic motors or medical devices where failure to meet a deadline could be catastrophic
- Soft realtime: there is a requirement to respond quickly most of the time (perhaps 99.99%+), but it is acceptable for the time limit to be occasionally breached providing the response on average is very fast. e.g. this is appropriate when performing realtime animation in a computer game - missing a deadline might cause a skipped frame but won't fundamentally ruin the gaming experience
Soft realtime is readily achievable in most systems as long as you have adequate hardware and pay sufficient attention to identifying and optimising the bottlenecks. With some tuning, it's even possible to achieve in systems that have non-deterministic pauses (e.g. the garbage collection in Java).
Hard realtime requires dedicated OS support (to guarantee scheduling) and deterministic algorithms (so that once scheduled, a task is guaranteed to complete within the deadline). Getting this right is hard and requires careful design over the entire hardware/software stack.
Here is a link to the answer: Is there a difference between a real time system and one that is just deterministic?
Was this a question sent to you in an email? I don't think the OR was a choice between these 2 options, but instead a choice between the common "non real-time" systems and a real-time/deterministic one.
As others have pointed out you may need clarification because "deterministic" and "real-time responses" could actually be subsets of each other BUT the other person may meant "deterministic or real-time responses" as ONE choice versus the implied common alternative of "non-deterministic and non-real-time responses".
So the question may have just been trying to narrow down a design decision between:
1) deterministic time or real time responses
- A system capable of deterministic and real-time responses such as an Arduino microprocessor with a realtime OS which would be able to respond to inputs in time to avoid causing damage
2) non-deterministic and non-real time responses
- A system like a raspberry pi running a non-realtime version of linux (such as Debian) that will not respond to inputs in a deterministic fashion but may be good enough for flashy lights and other situations where nothing can get damaged and nobody can get hurt if a servo or motor doesn't turn off in time
Deterministic time - relative to local system clock cycles/ticks. The system clock can jitter, drift, be paused, slowed up and slowed down, but all hardware and software components clocked off this main system clock will remain in perfect synchronisation. For example, a multi-threaded PC program can often be paused, providing all threads are paused and resumed simultaneously.
A good example would be a software simulation
Real time - absolute real world timing in s,ms,ns,us,etc. Timing must remain synchronised with one or more external interfaces, placing constraints on the speed, accuracy and continuity of the internal timings. E.g. PC driver software controlling a peripheral cannot be paused and resumed without losing a connection to the peripheral, and would cause the peripheral to fail or extra processing would be required to reestablish the connection.
A good example would be an embedded system.