real time

God root%bostonu.csnet at csnet-relay.arpa
Mon Nov 19 03:23:52 AEST 1984


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



More information about the Comp.unix.wizards mailing list