Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!linus!decvax!wivax!cadmus!harvard!seismo!brl-tgr!internet!God From: God Newsgroups: net.unix-wizards Subject: real time Message-ID: <5877@brl-tgr.ARPA> Date: Sun, 18-Nov-84 12:23:52 EST Article-I.D.: brl-tgr.5877 Posted: Sun Nov 18 12:23:52 1984 Date-Received: Wed, 21-Nov-84 05:28:33 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 31 Reply to Geoff Kuenning's comments: You misunderstood me. The hesitation was experienced only by a technician using a terminal to fill out medical questionnaires while another person was having a lung test NOT BY THE REAL TIME PROCESS!! Obviously someone has to suffer in favor of the real time demand. To be more specific, we were sampling a 14-bit A/D at about 1KHZ for about 5-10 seconds and performing averaging and volume to time-domain conversions within the driver at sample time. IE. the stuff had tighter restraints than you describe by at least a factor of 4. Well, a factor of 4 is splitting hairs, but it sounds like what we were doing is well within your definition of 'real-time'. The point is, either your processor is much much faster than your real-time needs or you have more than one processor or you allow delays in your non-real-time processes in favor of your real-time processes. My only suggestion was that given the price of small processors today (some of which are plenty fast enough for most real-time needs) the second choice might be worth considering. That, for example, is why DEC sells their Lab Peripheral System even tho VMS claims to be capable of real-time...why tie up a $500,000 VAX when a $15,000 system will do the real-time job? -Barry Shein (not Schein) Boston University