views:

699

answers:

13

I am having trouble deciding on whether to classify my application as 'real time' or 'near real time', or perhaps even something else.

The software receives data immediately as it is generated from the source, then based on certain rules, raises an alert when certain conditions are met. It takes the approach of checking the last 30 seconds of data every 30 seconds to see whether the criteria for a rule has been met.

Is that real time? What are the thresholds for the definitions of real time vs. near real-time?

EDIT

I think this is a duplicate of http://stackoverflow.com/questions/51135/define-realtime-on-the-web-for-business.

Please decide if the above thread is insufficient to answer your question.

A: 

I am in agreement with John, in your scenario you are looking at least 30 seconds of delay, I would say that it is nearly real time.

Mitchel Sellers
A: 

I would say the definition of real time would depend on the context. As with the music example real time would need to be milliseconds, but possibly with your example real time could be within 30 seconds or so. It's all relative.

Adam Driscoll
A: 

I think you need to look at the specific solution or part of the solution in where you need the response to be real-time. A real time response is one which is perceived by the receiver (the application or basically the end-user) as being real-time.

Per Hornshøj-Schierbeck
+3  A: 

Well, that could be more of a marketing question than a technical one.

Real-time, in terms of embedded hardware, involves a known fixed maximum time for handling incoming information (interrupts and the like).

You can certainly claim 30 seconds delay as real-time especially if the delivery of said information is longer than that.

For example, if your "alert" is an email that could spend 10 minutes in a mail server or a red cross on a monitor that the users only check every half hour, 30 seconds is more than adequate for real-time.

paxdiablo
A: 

Real Time deals with microseconds...mainly around robotics. Think 'move arm 30 microseconds; weld 1000 microseconds;', like in automobile assembly.

Is your 30 seconds based on a Thread sleep or a timer in a non-real time OS? If so, then you have a potential varience. Will you consider it a failure if you're outside that variance (30.01 seconds)? If not, then it's not real time.

Tom Carr
+2  A: 

I think one aspect that defines real-time is that the process is deterministic - that is, the application's response time is totally predictable based on the inputs.

Thus, painting with very broad brush-strokes, any app sitting on top of Windows can only be "near-real-time", at best. Doubly so if your app is running on some sort of sandbox platform (Java, .NET) where you don't have absolute control over platform functions (eg, garbage collection).

My personal rule is that "real-time" doesn't belong on a desktop PC; that's the realm of PLCs (and yes, they may be running OSes like QNX, VxWorx or even RTLinux).

moobaa
+12  A: 

Real-time = Guaranteed maximum time for resolution. It could be picoseconds or minutes depending on the application's requirements

This is StackOverflow's biggest problem: unqualified people answer LOTS of questions with answers that "sound right" and get voted up, people who care whether the answer is actually correct don't spew nonsense fast enough to earn rep to fix the wrong answers. Posting anonymously due to expected knee-jerk reactions.

Fully agree with you here, both on the answer and about uninformed posters answering questions on topics they don't know squat about.
Stu Thompson
Hey, it looks like SO is working now...the silly answers are dropping...
Stu Thompson
It would be great if SO would automatically downvote any answer that starts with "I think ..." or "In my opinion ...".But as Stu notes, the right answers usually do rise to the top, although it might take a few hours or days to do so.
Kristopher Johnson
A: 

I believe the answer is that realtime systems are subjective, in that "real time" is just timeliness contraints imposed by the requirements. Though clearly something that takes 2 hours to respond to a request is not real time, a 30 second delay might be fast enough to qualify as real time.

I work on what I consider real time systems, where when an event happens in the sytem it is immediately propogated to devices on the system, such that the delay in knowing about an update on a device is product of the network latency and the time take to update its in-memory data.

I personally wouldn't classify something with that polls for updates every 30 seconds as realtime. We have a web app as part of the afore mentioned system that does just that, it refreshes every 30 seconds, so the user is presented with data that is at most 30 seconds old. Contrast this with the win forms equalivent that is updated as soon as the event occurs.

Again, "real time" is bounded by your definition of a timely response.

rob_g
+5  A: 

The phrase "real-time" covers a fairly large patch of ground.

The vague definition is "software that acts within a bounded response time".

Where the boundary is hard e.g. in a car's injection control system, the software is said to be "hard real-time".

Where the boundary is soft e.g. in a music-playback system, where variations of up to 50ms are tolerable, the system is said to be "soft real-time".

So yes, for some definition of real-time, your system is real-time.

But you're probably going to get laughed at if you call it real-time around anybody else who actually works on real-time systems, because 30 seconds is pretty huge.

Noel Grandin
A: 

Another way to define "real-time" is by evaluating the capabilities of the many RTOSs (real-time operating systems). e.g QNX's definition is here. Notice that they conform to the POSIX PSE52 Realtime Controller 1003.13-2003 System product standard. Most embedded operating systems will provide similar functionality.

Bob Nadler
+8  A: 

Real-time is getting a required response to an event completed within the time period specified or your system fails.

People are used to thinking this must mean 'small number of milliseconds/microseconds' but that isn't necessarily true - it depends on your system.

If your system will fail if it doesn't complete it's required response within 30 seconds then it's 'real-time'.

For some systems, a fail could be catastrophic, e.g. causing multiple fatalities - this is described as safety critical, e.g. shutting down a nuclear power plant.

YermoungDer
+1  A: 

Definition of 'hard' real-time from my controls friends - Late information is wrong information. If it needs to be there every 1s and it gets there in 1.1s, it's useless for calculations.

Stephen Friederichs
I think this is the best definition here. Real-time doesn't imply a specific regime of "speed" -- it means that program correctness is defined not simply as the correct output, also delivering that output at the correct time (which may be deterministic, but maybe not, and could be defined in nanoseconds, minutes, or even days!) --JA
andersoj