roelof@idca.tds.PHILIPS.nl (R. Vuurboom) (06/02/89)
In article <20796@winchester.mips.COM> mash@mips.COM (John Mashey) writes: > >Maybe some real time folks could post some references, or some descriptions >of the different flavors of real-time (as there are quite a few). Actually I really only know two. First off my definition of real-time system: The fundamental characteristic of a real-time system is its ability to - meet external time constraints while showing correct functional behaviour (extrinsic). - satisfy the following thoughput/load curve (intrinsic): ^ throughput | | x x x x x x x | x | x | x |x -----------------------------> load and _not_ ^ throughput | | x x x | x x | x x | x x x x |x -----------------------------> load In other words the system must never collapse if it can't absorb the load. If you're willing to accept this definition (which you may not be) then you'll probably accept the premise that real-timeliness is something also extrinsic as well as intrinsic to a system. It is the importance of the time constraints (in relation to other types of constraints) and the ability of the system to follow the throughput/load curve that determines how "real-time" a system is. The two flavours stem (as I see it) from how much design effort must go into satisfying time constraints in 1. normal conditions 2. abnormal conditions Case 1 will lead to designs where the performance criterium reigns. Case 2 will lead to designs where predictibility rules the roost. A statistical sampler is probably a good example of 1. If I can process on average 50000 samples a second then I probably may not care if I lose samples every now and then because they arrived too close together. Of course I've deliberately used 50000 as a number instead of 2 or 3 because of the implicit assumption that having only 20 microseconds to process may require special algorithms and/or hardware. The assumption here is that "processing a sample" will cost some 10's to 100's of lines of code. Maybe 1000 instructions which translates to 50 mips: outside the range of todays _standard_ hardware/software control systems. A flight control system is the obvious example of case 2. If the fuselage top blows off (known to happen) and the plane flips into a nose dive (which luckily didn't) there's probably going to be a lot requests for processing coming in at the same time. You can't afford to miss a single request (to adjust the flaps). You want _predictibly_ correct behaviour. At worst you process the commands more slowly but you _never_ collapse under the load. _Both_ flavours however should follow the throughput/load curve to qualify for "real-time" in my opinion. -- Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof