This website has the term “Real-Time” in its title but what do we really mean when we use the term? Here, RT Insights International Technology Editor Dr. Opher Etzion discusses the four types of “real-time” and whether or not we are using the term correctly in all instances.
So, let’s first discuss the notion of real-time. The popular belief is that real-time equals very fast but this is not really what real-time is about. We can define real-time by using two metrics:
1. A deadline by which a certain action should be taken, and
2. A utility function which designates the amount of benefit or damage inflicted by the fact that the action is taken or not taken as a function of time.
By using these two metrics, we can observe four types of real-time:
1. Soft Real-Time
It is possible to act after the deadline but the utility decreases (maybe quickly) and, at some, point gets to zero at which point the action will have no effect. The utility function does not get to negative values which means that no damage is inflicted.
2. Firm Real-Time
The utility function goes immediately to zero when the deadline is missed; there is no use taking an action after the deadline but, again, no damage is inflicted.
3. Hard Essential
If the deadline is missed, then the utility function goes to a negative value; the damage is growing as a function of time until the action is achieved.
4. Hard Critical
This is missing the deadline; here the utility function goes immediately to “minus infinity” which means a catastrophe will happen.
So, real-time is not about fast but about missing the deadline. The linkage is there; if the deadline is very short (i.e., needs to react within 1/1000 of a second) but many deadlines are longer than that—seconds, minutes, hours or days—depending on what is needed to react to.
For example, the contract that we have with our local electricity company says that, when a problem is reported, they should start fixing it within two hours. Or the deadline for the delivery of pizza in one of our local delivery centers is 40 minutes, otherwise it is free of charge. So, most of the the world typically does not work in milliseconds.
When talking about Quality of Service (QoS) measurements, they can be either statistical (e.g., in 90 percent of the cases, the deadline should be reached) or individual (e.g., for all of the cases, the deadline should be reached). Typically, there are different scheduling strategies to achieve each of them. For the individual case, it is important to have a consistent deterministic reaction; this is a source of the various implementations of Real-Time Java.
Since Java is non-deterministic by its nature of garbage collection which happens in undetermined times and lasts for undetermined durations, this may work for the statistical case but not for the individual case. Real-Time Java does not stand for Java which runs much faster but for Java in which the garbage collection differences are smoothed, thus its reaction is (more) deterministic.
What other real-time measurements are there?
In event processing, latency can be measured by the end-to-end (i.e, from the time that the event happens in reality to the action being taken in reality), can be related only to the event processing part (i.e., from the time the producer sends the event until the time the consumers receive the consequences of this event), and can relate to a specific function (i.e, agent) in the event processing network. So, when latency is mentioned, it should be defined. What is really being measured? The deadline typically refers to time constraint of the latency.
When we talk about real-time in the spoken language and in the marketing language, we often mix several things. Sometimes we talk indeed about real-time in the sense that we are reacting to some situation and there is a need to react in timely manner otherwise the reaction will not be relevant. Medical conditions are an example of this. In some situations there are indeed hard real-time constraints while in other cases there are soft real-time constraints that are dictated by the treatment protocol.
There are also many examples from another domain: transportation control systems which need to react to changes while it is still possible to eliminate a traffic jam, for instance. In this example, the real-time deadline is also calculated based on the case. Sometimes we talk about real-time when we actually mean “online” and not “batch.” If we’re doing something within the process and not periodically, then sometimes we really mean that we need to react “as soon as possible.”
My interpretation to “real-time business insights” is that, indeed, we are talking about real-time but, in many cases, it is a soft real-time. It is important to try to define not only the deadline but also the utility function in order to evaluate if late reaction is worthwhile or not.
