What constitutes 'real time'

怎甘沉沦 提交于 2019-12-05 01:59:50

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.

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.

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.

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.

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).

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.

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.

I provide a lengthy discourse on this on my web site real-time.org. The home page has a temporary link to a briefing. The briefing discusses how and why people don't understand what "real-time" (and "hard" and "soft" and "predictable" etc.) means. It provides some precise and general definitions. I have heard from people who don't agree with my explanation of this topic, but none of them have come forward with anything remotely as precise and general as mine. "Pull up a chair, let's talk" as Larry King says.

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.

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.

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.

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.

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!