Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!rochester!pt.cs.cmu.edu!fas.ri.cmu.edu!dstewart From: dstewart@fas.ri.cmu.edu (David B Stewart) Newsgroups: comp.realtime Subject: Re: Re^2: What is "real-time" really? Message-ID: <8462@pt.cs.cmu.edu> Date: 17 Mar 90 19:26:03 GMT References: <98692@linus.UUCP> <1990Feb24.195542.21454@newcastle.ac.uk> <98987@linus.UUCP> <8178@pt.cs.cmu.edu> <1815@neon.siesoft.co.uk> Organization: Carnegie-Mellon University, CS/RI Lines: 79 In article <1815@neon.siesoft.co.uk> huw@xstuart.siesoft.co.uk (Huw Roberts) writes: >My (well, actually paraphrased from Yan Wong of STC's) definition of a >Real-Time-System is: >"One in which the functional constraints are such that they compell the >implementors of the system to ensure that the system hardware is ALWAYS >underutilised". Try explaining that to the people buying the equipment. We have robots that MUST run at rates of 500Hz or above for some control schemes. That means one of three things: - Use up as much CPU bandwidth as possible (approx 85%; the other 15% goes to OS) - Use multiple processors; but the communication overhead sometimes removes the advantage of making it run in parallel, or the code cannot be parallelized very easily; - Buy faster CPUs, but how do you explain to your boss: "I am using up 85% of the bandwidth, I need a new CPU to use up only 50% of it". I agree that a system should be left underutilized, but it is not always possible. >In other words, the CPU must never hit 100%, the disks (if any) must never >thrash and there will always be memory bandwidth available. Thrashing will occur if your disk gets over 90% full or your memory is overutilized, but not if your CPU is fully utilized. There is no reason for a CPU not to be running 100% of the time. For that matter, if you don't give the CPU anything to do, it will spend its time seeing how high it can count :-). Slowdowns occur when you request more than 100% (or say 80% when you consider OS overhead). Any requests above 100% will have to wait until the CPU gets to it. This is not so unusual; suppose you run two instances of 'spice' (or some other numerically-intensive program) in the background at the same time. You are requesting 200% utilization; in a time-sharing environment you just let them go each their turn. In a real-time environment, however, you decide which of the two processes to run depending on when they should finish. If both instances are equally important, then they have equal priorities. However, if one must finish within 1 second and the other within 5 seconds, then it is a real-time problem. >So, the payroll example cannot be a Real-Time-System because the machine is >allowed to be fully utilised towards the end of the month. I disagree with this statement. The utilization of a system has nothing to do with whether or not a system is Real-Time. My original statement about utilization specifically said that the problems with real-time systems are much more apparent when utilization is higher, since the ability to meet timing constraints becomes more difficult. >A multiplexor IS a real-time-system because if the CPU >usage ever hit 100% and a new message arrived, then some of the data is lost >and the system fails to meet its requirements. The implementors are >constrained to ensure that the system is underutilised. Not true. The system may be *fully* utilized; it just cannot be *overutilized*. There are no rules saying it must be underutilized. Ever hear of buffering a message? A buffer is used so that when more than 100% of utilization of a resource is requested, the requests are put on hold until the resource is free. This allows a system to operate as long as *average* utilization is below 100%. As for your example, you say "the system fails to meet its requirements". What requirements? The requirements that there be at most N items at once? Where is the time? You seem to have mixed 'resource constraints' with 'timing constraints'. Your requirement for underutilization is not a time constraint, and thus not a real-time problem. Of course it is a different story if you have both 'resource' AND 'time' constraints, then it IS a real-time problem, and possibly a difficult one (i.e. the topic of much research in real-time systems). ~dave -- David B. Stewart, Dept. of Elec. & Comp. Engr., and The Robotics Institute, Carnegie Mellon University, email: stewart@faraday.ece.cmu.edu The following software is now available; ask me for details CHIMERA II, A Real-time OS for Sensor-Based Control Applications