huw@xstuart.siesoft.co.uk (Huw Roberts) (03/16/90)
I once heard a fairly glib but thought provoking definition of a real-time system which I believe summarizes the concept nicely (Please excuse any spelling mistakes as I've got some sort of viral infection :-) ). David Stewart comes very close with his statements but he misses the fact that this is the defining point of a real-time-system: >.....because we are talking on the order of magnitude of "days" >instead of seconds, most computer systems are fast enough to handle this task >using a conventional operating system, only because they have so little to >do compared to the amount of time they have; what if that one computer >had a million things to do, in a very specific order; would it succeed? >That all depends on how it is programmed ... and at that point it would >be a real-time system. >One note about real-time systems: Few problems occur on under-used >systems, since there is enough time to do everything. The timing constraints ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >start to cause problems on a system that is running at near capacity. >Because applications running on the order of milliseconds are much more >likely to be hitting the full bandwith of the CPU then an application >running on the order of days (it takes lots and lots of stuff to keep >a computer busy for days non-stop), they are the ones most likely to >require the special real-time techniques ... i.e. considering time >as an important factor in all equations. 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". In other words, the CPU must never hit 100%, the disks (if any) must never thrash and there will always be memory bandwidth available. 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. In addition, a system with real-time elements may not be a complete real-time-system because the implementors are (for example) using up waste cycles to calculate mandlebrot sets. 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. Huw Flame me please! (Although turn around may well be a month). ------------------------------------------------------------------------------- Name Huw Roberts Siemens Plc., System Development Group, Mail. huw@siesoft.co.uk Woodley House, 65-73, Crockhamwell Road, Tel. +44 734 443068 Woodley, Reading, Fax. +44 734 698874 Berkshire, RG5 3JP England. ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- Name Huw Roberts Siemens Plc., System Development Group, Mail. huw@siesoft.co.uk Woodley House, 65-73, Crockhamwell Road, Tel. +44 734 443068 Woodley, Reading, Fax. +44 734 698874 Berkshire, RG5 3JP England. -------------------------------------------------------------------------------
dstewart@fas.ri.cmu.edu (David B Stewart) (03/18/90)
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