Near Real Time

Near Real Time means effectively RealTime but without guarantees of hitting specific deadlines. Also known as soft real time (as opposed to hard real time).

For example ErlangLanguage is used in NearRealTime telecommunications and Internet applications, e.g. in switches, etc. It is a dynamic language with a NonRealTime? garbage collector. It does not have specific deadline capability, but it effectively works in practice.

This does not imply that a NearRealTime system that works in practice could work in true RealTime. You cannot count on it to do so.

The term Near Real Time is also sometimes used to mean that users see data that is only a few seconds old. (But purists favor the above definition.)

Actually, purists use "real time" and "other." If it isn't truly real time then it isn't. There is no substitute.

As a purist, I use the phrase soft RealTime to refer to conditions where we can make probabilistic guarantees about delay - e.g. when we can assert that delays are bounded by a Poisson distribution or Bell curve. This seems to be a much stronger assertion than 'NearRealTime', since it still involves a useful guarantee even without the 'hard' deadline boundaries.

You, sir, are simply not a purist in any sense of the word. If a system has fully predictive latency then it is real time. If it does not then it isn't -- that's how real time systems are defined. Period. There is no "near real time," no "soft real time," no "probabilistic real time," nor any other blather. It's real time or it ain't.

Not even 'hard RealTime' systems have "fully predictive latency". They have upper bounds, and sometimes lower bounds. Latencies are never fully deterministic down to the hardware layer. Issues such as metastability and clock drift prevent such a thing. I'm a purist in the sense that I won't call a system RealTime unless it can be proven; in the industry, unfortunately, the word gets bandied about even for aviation software without any formal analysis. I would guess you're not involved with RealTime systems of any sort, just contributing here to 'out-pure' me for kicks and grins.

The use of this term within the purist category of "other" is a recognition of necessary processing and presenting time frames. Illustration: We cannot observe the Universe in "RealTime" because of physical separation distances involved. In the computing sense, NearRealTime is a recognition of this taking into consideration that what we observe is in reality a "playback" of the real thing, since it has been through a process of encoding-storage and decoding-presentation and the attendant time requred for the operations. -- DonaldNoyes.20110706

RealTime does not mean zero latency. It means controlled latency. Delays are acceptable where we can make guarantees about them and still meet system timing requirements. We do not say 'NearRealTime' when we have delay; we say it when we cannot bound the delay.

A video camera cannot observe the universe. It can only observe the light that strikes the sensitive elements on the camera. That light might carry information about locations distant and in the past. We can call such a system 'RealTime' if the information in the video is processed at the same rate it is obtained, such that we can guarantee the delay between receiving a frame and updating our information, as opposed to requiring a later batch effort.

Consider this:

I am sure that segments and intervals of time can be reproduced to appear in dependable and predictable manner such as to be effective in part, but I am speaking of NearRealTime in such a manner as to allow information and control interchange two-way-simultaneous in packets which are longer in duration than the magnitudes of the two-way delay.

This is if response requires processing before response, or is dependent in the case of control on the receiving end's process response to changes commanded. It he interchange is over great distances and the command increments are small (less than complete sequences and not autonoumus or semi-autonomous), task completions are difficult, or severely drawn out. Such is the case in controlling a robotic vehicle say at a distance of Mars. Instead of commands, one must depend upon sequences with local feedback and control or near autonomous decision and control. Other real-time problems occur when both processing units misunderstand or only partly process the information being exchanged, as in when the receiving party begins a return exchange before processing the complete message from the sending party. This most often results in an interrupted or halted exchange.

It is true that, as we increase delay or risk of disruption, we must simultaneously increase autonomy. That doesn't mean we can't have RealTime, but we do need to specify our actions on appropriate time scales. For example, light-speed round-trip to Mars is 11 to 44 minutes depending on relative orbital, so at that level we would need to schedule actions that take on the order of at least a couple hours to complete. Currently, of course, we are limited to an orbiting communication satellite above Mars, so our real communication delays are up to a day, and thus even longer missions are required. Low-level teleop (move arm 3cm to left) would be grossly inefficient and unsafe, but we could provide a route or patrol mission. Any code we transmit for autonomous behavior can potentially make real-time decisions at a much finer scale.

Anyhow, it seems you conflate 'RealTime' with 'interactive'. From connotation, that is understandable - we almost always use 'RealTime' in reference to interactive systems. But the meanings are different: RealTime is simply about meeting timing constraints. Those timing constraints might be microseconds, or might be hours. Granted, we could never meet the temporal requirements for teleoperation of a Mars rover... but choosing sane requirements is a separate issue.

Not only are timing constraints important, but also the dependency on time as a function in rates of change, as in the failed mission which was the result of confusing english and metric expressions of velocity to determine the magnitude and timing of the velocity change component of the mission. Requirements may be separately and singly understood, but when employed in connection with another component using differing usages in length, velocity and acceleration the result of which, in this particular critical operation, resulted in an unrecoverable and destructive result.

Clearly communicating requirements is important, but I'm not sure what it has to do with the topic of this page.

See: DelayTolerantNetworking

CategoryTime