Path: utzoo!attcan!uunet!ginosko!brutus.cs.uiuc.edu!tut.cis.ohio-state.edu!
ucbvax!XP.PSYCH.NYU.EDU!aries
From: ar...@XP.PSYCH.NYU.EDU (Aries Arditi)
Newsgroups: comp.sys.sgi
Subject: real-time and 3D workstations
Message-ID: <8909081349.AA26475@cmcl2.NYU.EDU>
Date: 8 Sep 89 13:40:37 GMT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 45
I've been following the discussion following your request to info-iris for
a machine on which to conduct your experiments. I'm afraid that most of
the discussants don't quite understand what the demands of an RT
experiment are. The IRIS machines, and most other 3D workstations are
UNIX based, which almost by definition means they are NOT real-time in the
sense you need for accurate measurement of time. Depending on what is
happening at any given time, any number of processes are competing for the
CPU's time. This means that you will always have some uncertainty as to
the onset of your stimulus. Additionally, you will have some uncertainty
as to the button time, unless you have an external real-time clock hung on
the back (Personal IRISes have only one VME bus slot, so only 1 such
device can be on your system at once), and even then, since you don't know
exactly when the stimulus onset was, you still have error.
I think the IRIS sounds like the machine in your price range to generate
your stimuli, but may or may not be depending on how accurately you need
to measure RT. Here are 2 possible solutions:
1. There are versions of "real-time" UNIX available (I know not where, but
someone at AT&T Murray Hill developed one of them for DEC PDP 11's.
Possibly an SGI sales rep will do some legwork to find one for you if he
thinks that's necessary to make the sale. In the PDP 11 market, these
real-time versions of UNIX varied quite extensively both in quality, I
understand, and in the extent to which they are "real-time." So be careful
here. You will need to know that you can still run the software for your
experiment, under this operating system.
2. The solution I have used with some success, on another multi-tasking
(i. e. not real time) machine, is to count video frames when measuring
time, rather than waiting for an interrupt from a clock or other device.
It's very easy, but your accuracy is limited to +/- 16.66667 msec. If
that's OKAY for your application. Sometimes you can degrade your stimulus
or task in some irrelevant way in order toraise all your RT's so 17 msec
isn't such a big deal.
Anyway, computer graphics people usually think that real-time just means
animated, so watch out for that.
Good luck.
-Aries Arditi
Vision Research Laboratory
The Lighthouse
111 E 59th Street
New York, NY 10022
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sgi!...@patton.sgi.com
From: j...@patton.sgi.com (Jim Barton)
Newsgroups: comp.sys.sgi
Subject: Re: real-time and 3D workstations
Message-ID: <41523@sgi.sgi.com>
Date: 11 Sep 89 15:15:31 GMT
References: <8909081349.AA26475@cmcl2.NYU.EDU>
Sender: j...@patton.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 57
In article <8909081349.AA26...@cmcl2.NYU.EDU>, ar...@XP.PSYCH.NYU.EDU
(Aries Arditi) writes:
>
[ ... discussion of some aspects of RT UNIX ... ]
>
> I think the IRIS sounds like the machine in your price range to generate
> your stimuli, but may or may not be depending on how accurately you need
> to measure RT. Here are 2 possible solutions:
>
> 1. There are versions of "real-time" UNIX available (I know not where, but
> someone at AT&T Murray Hill developed one of them for DEC PDP 11's.
> Possibly an SGI sales rep will do some legwork to find one for you if he
> thinks that's necessary to make the sale. In the PDP 11 market, these
> real-time versions of UNIX varied quite extensively both in quality, I
> understand, and in the extent to which they are "real-time." So be careful
> here. You will need to know that you can still run the software for your
> experiment, under this operating system.
Actually, IRIX has some real-time features which may be adequate for this
application. First, it is possible to fix a process priority and thus
exempt it from normal priority degradation. These are various priorities
supported, and of course the highest is gauranteed control of the processor
when it wants. Fine grained memory locking, which is probably not needed
for this application, allows total control over what's in memory.
> 2. The solution I have used with some success, on another multi-tasking
> (i. e. not real time) machine, is to count video frames when measuring
> time, rather than waiting for an interrupt from a clock or other device.
> It's very easy, but your accuracy is limited to +/- 16.66667 msec. If
> that's OKAY for your application. Sometimes you can degrade your stimulus
> or task in some irrelevant way in order toraise all your RT's so 17 msec
> isn't such a big deal.
The accuracy of gettimeofday() is 1 millisecond, which should be
more than adequate for human/machine interaction (which is on the order of
tenths of seconds). Using itimers gives interrupts at a 100HZ rate,
or as pointed out you can use the graphics system frame rate as a clock
as well.
> Anyway, computer graphics people usually think that real-time just means
> animated, so watch out for that.
Some of use know what REAL real-time means, even though we do graphics too.
IRIX is a "soft" real-time system, in that the mechanisms for gauranteed
response and resource control are good down to ~1 millisecond. A "hard"
real-time system doesn't run UNIX and can get down to 10's of microseconds.
Human/machine interaction is definitely "soft".
> Good luck.
> -Aries Arditi
> Vision Research Laboratory
> The Lighthouse
> 111 E 59th Street
> New York, NY 10022
-- Jim Barton
Silicon Graphics Computer Systems "UNIX: Live Free Or Die!"
j...@sgi.sgi.com, sgi!...@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb