> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > On Thu, Jul 20, 2000 at 12:01:30PM +0200, David Balazic wrote: > > > Yes , but not every process has usec requirements. > > > Think house heating control etc ... > > > > So deterministic response is necessary for all hard RT, but the range > > of hard RT problems that can be solved is a function of worst case > > latencies. > > I thought that I saved it, but I didn't. This came up a while ago > (I think under a subject of "definition of realtime") and a useful > distinction was made. > > Soft real-time: If the deadline is missed, the value of the system > begins to decrease at some rate. > > | > ^ | > | **************** > v | * > a | * > l | * > u ----------------------------------* > e | time-> > deadline > > "Firm" real-time: If the deadline is missed, the value of the process > immediately becomes some finite value <= 0. > > | > ^ | > | **************** > v | > a | > l | > u ------------------------------------ > e | time-> > | > |************** > | > deadline > > Example of soft real-time: streaming data to a CD-R buffer. It's not > ideal if the streaming interrupts, but not immediately catastrophic. > Eventually you're going to have a coaster if you don't catch up. > > Example of "firm" real-time: Winprinters. The CPU more-or-less controls > the print head directly. If you can't get the data to the print > head fast enough, you might as well start over. You waste a sheet of > paper and some quantity of ink. > I don't get the difference between soft and firm realtime. in your sample you are making the printer hard realtime, that means if you miss a deadline you lost. I don't see any point in maping a technical definition to the consequences it might have, so if what happens is bad its hard realtime if its not so bad its firm realtime and if it gets wors slowly its soft realtime..... An example for this problem would be a DAQ-module, if the same DAQ-module is used for the robot and for the printer it is obvious that the system can't be considered both firm and hard realtime , distinguishing by the machine it was poped into makes no sense . So I think you need an abstract criteia , and that is , "a deadline may be missed" or "no deadline may be missed". also your definition with "the value of the process..." what is the value of a process ? and what is scale and measure of this value ? I guess the only usable quantitative values to describe a realtime system are maximum response time : being the worst case response time the system ever will have when a request occures. average reponse time : probalby only sensible if one gives some environment data like system load and sample-rate sample-length aswell. timing resolution : that is how precicely can a time mark be hit if it is known a-priori . hofr.at -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
