Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ukma!nrl-cmf!ames!killer!linimon From: linimon@killer.UUCP (Mark Linimon) Newsgroups: comp.os.misc Subject: Re: timeliness of real-time [was: Re: Realtime OS's] Summary: parameters of real-time Keywords: Realtime Message-ID: <4702@killer.UUCP> Date: 5 Jul 88 19:22:30 GMT References: <10450@udenva.cair.du.edu> <8411@pur-ee.UUCP> <797@taux01.UUCP>Organization: The Unix(R) Connection, Dallas, Texas Lines: 33 In article , webber@aramis.rutgers.edu (Bob Webber) writes: > Of course, my own interests are in... > being able to guarentee that certain things will get done in a given > 60th of a second time slice. Is this the same neighborhood the ``real'' > realtime people are interested in, or do they want finer grain control? > > --- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber) > To some extent, the phrase "real-time" has become marketingspeak. Several classes of applications exist. Heavy image processing applications may require response down in the 1 to 10 microsecond range. (Obviously beyond a certain point you have to build dedicated hardware, sometimes in conjunction with a slower microprocessor. This is fairly common). Machine control applications oftentimes are satisfied by response times in the low milliseconds. Most anything moving a stepper motor or engaging a solenoid will be in this category. As far as I can tell the common denominator that various people use the "real" in "real-time" to mean, is that the response is *guaranteed* to happen within this time. In this sense an (untweaked) Unix kernel is not real-time, due to its statistical behavior. (Several manufacturers have done such tweaking, by the way). I am currently trying to gather together my notes and lists of various real-time products on the market. Further input solicited by email, I will try to summarize to this newsgroup within two weeks, maybe by the end of this week. Mark Linimon Mizar Digital Systems sun!convex!mizarvme!linimon