From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.8 required=3.0 tests=BAYES_50,FILL_THIS_FORM autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 19 Oct 92 20:17:34 GMT From: bloom-picayune.mit.edu!mintaka.lcs.mit.edu!spdcc!merk!alliant!russ@bloom- beacon.mit.edu (Russell McFatter) Subject: Re: What is "real-time"? Message-ID: <1992Oct19.201734.29991@alliant.com> List-Id: In article <1992Oct17.012952.13340@afit.af.mil> mawhelan@afit.af.mil (Michael A . Whelan) writes: >Real-time software does not have to be fully deterministic. It has to >meet the deadlines of the application domain for a response. The key is [...] > The reason is the responses were >deterministic. Even to the guy shooting. Again, the key is meeting a >response time requirement for the application domain, not a fully >deterministic system. > [...] > >Mike Whelan > No! When I said "deterministic", of course, I meant time-domain determinism, not that the code produces the same output (responses) to different input (stimuli)! The other suggestions being bantered around ("must produce a result or act on the data before the required deadline") are also weak, at best. Put your own personal definitions of "real-time" through the following quiz: 1: Is a system "real-time" if it completes processing input data substantially faster than it did the same input on a previous "run", EVEN THOUGH both attempts met the required "deadline"? Answer: NO. As a real-time developer, you would be as concerned of results coming back too early as you would of them coming back too "late". Why? Because, theoretically, if the system completed the processing "quickly" on the faster pass, something unrelated to the system itself-- a total unknown-- delayed the "slow" pass. You would be correct to worry that this unknown might cause you to miss the deadline at some point in the future. (Obviously, conditions known to the developer-- such as the presence or absence of higher- priority tasks, can affect time-to-solution even though they are not "unknowns"). 2: Does a real-time system ALWAYS process input in the same (deterministic) time? Answer: NO. Many applications' performance depends on the kind or amount of data being processed. The key is that the timing is, at least, *predictable*. That way the designer knows that the system will meet the specifications under all of the specified conditions. 3: Does real-time code always meet its deadlines? Answer: NO. The deadlines are only guaranteed to be met when the work meets the criteria that the real-time system is certified for. The specifications may or may not say what is to be done if the deadlines cannot be met. Your phone system, for example, is a real-time system to a great extent-- at certain times. On "older" switches, for example, your line was polled about ten times per second when your phone was on the hook, to see if you had picked it up or not. After picking up the phone, the system had to provide a dial tone within a certain amount of time, at which point the line is scanned about 100 times per second for dial pulses/DTMF. What if every phone on the switch is picked up at once? Well, that's outside the specifications for "real-time" behavior, so the switch is free to fall into some kind of backup strategy (resulting in very long wait for dial tone, error tone or other message, or perhaps, if this situation was not anticipated in the specs, a complete collapse of the domestic dial network). A real-time application might detect this kind of situation by prequalifying the input ("Hmmm... I count 8 radar targets... I know I can't handle that many in the time requirements, so take the first 6 and put up a warning to the operator"), or by an OS-supplied scheduler feature. For example, a frame scheduler might provide two different behaviors on frame overruns-- one preempts the process whose frame has ended, thus preventing it from interfering with possibly "more critical" processes in adjacent frames; or it might allow the process to continue, but send it an "overrun" signal or interrupt that it can use to somehow change its behavior ("I haven't been counting radar targets, but I'm not meeting my deadline. I'll start ignoring targets beyond a certain distance and will warn the operator.") 4: Parts of a "real-time" system can be nondeterministic, but the results can still be considered "real-time". Answer: TRUE. Example: You have a fairly slow PC running a bulletin-board system. Your *only* specification: The BBS must allow 1024-character typeahead at rates of up to 2400 baud, under all circumstances. You collect a username and password, and then access a floppy-disk to look up the user information. This might take anywhere from 3 to 30 seconds, and is entirely nondeterministic; meanwhile the user might be blasting away at a full 2400 baud. HOWEVER: You implemented the serial connection using an interrupt handler at a higher priority than the floppy drive; thus no characters are lost (even though the floppy access might slow to a crawl). Your BBS meets your own "real-time" criteria despite the fact that the non-critical components are nondeterministic. Of course, if some other interrupt is possible at a higher priority (say a mouse or other external device), the system no longer meets the "real-time" requirements. If you were requiring *unlimited* typeahead, the specs would be a bit harder to meet. If you're asking: How can this setup be considered "real-time" at all? Suppose for the moment that the PC is receiving data once an hour from a real-time system that has a deterministic time in which to connect to the PC, transmit a username/password and some sort of data, then disconnect (regardless of response from the PC) and get on with its other work. Simple "real-time" requirements can almost always be faked in hardware (by passing off the task to some dedicated device that has nothing "better" to do). Example: A terminal multiplexor. It has its own buffer, does its own character echoing, and generally won't lose input even if the main CPU takes a "long" time to get around to reading from it. You can even bring the entire machine to a stop and the multiplexor keeps on handling user input-- to a point... ip00> mti: duart overrun (059004, -1): 5: A system is either clearly "real-time" or not, regardless of its purpose. Answer: FALSE. You might consider that there is a *scale* to real-time events; a range of "legal" nondeterminism for a particular kind of event to happen-- an allowable "plus or minus" that is still, for "all practical purposes", deterministic. For example, no computer system can be more time-deterministic than its own clock frequency allows for. A credit-card authorization network might be documented to have a deterministic response time of "8 seconds" for any successful transaction, and "no more than 11 seconds" for any unsuccessful one. It is reasonable to say that an "approved" response will never happen in four seconds, or forty seconds, when the system is behaving properly-- but, for the purposes intended (to not keep the customer waiting), 8.1 seconds might be considered within the "deterministic" window, and given the variable delay of the phone transmission itself, the variation is unavoidable. An additional note: Be very careful when using the word "critical" to discuss real-time systems and components, because the word has so many meanings. Example: which of the following is more "critical"? 1: A task which controls firing of an automobile's spark plugs 2: A task which controls the Space Shuttle's brakes in response to the pilot's controls Well, in the first case, the misfiring of a spark plug probably won't kill anyone. However, the *timing* is critical-- if off by even a tenth of a second, the entire engine won't run (or could be irreversibly damaged). On the shuttle, a delay of even two entire seconds in applying the brakes would be unlikely to endanger the mission or anyone on it, given the length of the runway. The real-time "scale" and the "failure penalty" are entirely independent, even though the word "critical" is often used to described both. --- Russ McFatter [russ@alliant.com] std. disclaimers apply.