Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><a href="https://stackoverflow.com/tags/real-time/info">https://stackoverflow.com/tags/real-time/info</a></p> <h2>Real-Time</h2> <p>Real-time means that the time of an activity's completion is part of its functional correctness. For example, the <code>sqrt()</code> function's correctness is something like</p> <blockquote> <p>The sqrt() function is implemented correctly if, for all x >=0, sqrt(x) = y implies y^2 == x.</p> </blockquote> <p>In this setting, the time it takes to execute the <code>sqrt()</code> procedure is not part of its functional correctness. A faster algorithm may be better in some qualitative sense, but no more or less correct.</p> <p>Suppose we have a mythical function called <code>sqrtrt()</code>, a real-time version of square root. Imagine, for instance, we need to compute the square root of velocity in order to properly execute the next brake application in an anti-lock braking system. In this setting, we might say instead:</p> <blockquote> <p>The sqrtrt() function is implemented correctly if </p> <ol> <li>for all x >=0, <code>sqrtrt(x)</code> = y implies y^2 == x and </li> <li><code>sqrtrt()</code> returns a result in &lt;= 275 microseconds.</li> </ol> </blockquote> <p>In this case, the time constraint is not merely a performance parameter. If <code>sqrtrt()</code> fails to complete in 275 microseconds, you may be late applying the brakes, triggering either a skid or reduced braking efficiency, possibly resulting in an accident. The time constraint is part of the functional correctness of the routine. Lift this up a few layers, and you get a real-time system as one (at least partially) composed of activities that have timeliness as part of their functional correctness conditions.</p> <h2>Near Real-Time</h2> <p>A near real-time system is one in which activities completion times, responsiveness, or perceived latency when measured against wall clock time are important aspects of system quality. The canonical example of this is a stock ticker system -- you want to get quotes reasonably quickly after the price changes. For most of us non-high-speed-traders, what this means is that the perceived delay between data being available and our seeing it is negligible.</p> <p>The difference between "real-time" and "near real-time" is both a difference in precision and magnitude. Real-time systems have time constraints that range from microseconds to hours, but those time constraints tend to be fairly precise. Near-real-time usually implies a narrower range of magnitudes -- within human perception tolerances -- but typically aren't articulated precisely.</p> <p>I would claim that near-real-time systems could be called real-time systems, but that their time constraints are merely probabilistic:</p> <blockquote> <p>The stock price will be displayed to the user within 500ms of its change at the exchange, with probability p > 0.75.</p> </blockquote> <h2>Batch</h2> <p>Batch operations are those which are perceived to be large blocks of computing tasks with only macroscopic, human- or process-induced deadlines. The specific context of computation is typically not important, and a batch computation is usually a self-contained computational task. Real-time and near-real-time tasks are often strongly coupled to the physical world, and their time constraints emerge from demands from physical/real-world interactions. Batch operations, by contrast, could be computed at any time and at any place; their outputs are solely defined by the inputs provided when the batch is defined.</p> <h2>Original Post</h2> <p>I would say that real-time means that the time (rather than merely the correct output) to complete an operation is part of its correctness. </p> <p>Near real-time is weasel words for wanting the same thing as real-time but not wanting to go to the discipline/effort/cost to guarantee it.</p> <p>Batch is "near real-time" where you are even more tolerant of long response times.</p> <p>Often these terms are used (badly, IMHO) to distinguish among human perceptions of latency/performance. People think real-time is real-fast, e.g., milliseconds or something. Near real-time is often seconds or milliseconds. Batch is a latency of seconds, minutes, hours, or even days. But I think those aren't particularly useful distinctions. If you care about timeliness, there are disciplines to help you get that.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload