Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!snorkelwacker!think!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!lll-winken!ames!pasteur!ucbvax!hplabs!hpda!hpcuhc!edwardm
From: edwardm@hpcuhc.HP.COM (Edward McClanahan)
Newsgroups: comp.sys.next
Subject: Re: NeXT and Real-Time
Message-ID: <680022@hpcuhc.HP.COM>
Date: 1 Mar 90 21:01:35 GMT
References: <8196@pt.cs.cmu.edu>
Organization: Hewlett Packard, Cupertino
Lines: 71

Jean-Christophe Dhellemmes asks:

> Real-Time on the NeXT ?
> =======================

> I am interested in real-time applications on the NeXT machine. I know that
> the current version of Mach for the NeXT doesn't support such capabilities,
> but I was still hoping I can get good enough performances on the machine for
> my needs. Until today.

Not knowing much about Mach, is it true that user processes can't preempt
page faulting, etc...?

> I did some simple tests using the Mach system calls to get the real time
> system clock, and found out that the call to gettimeofday(2) take about 160
> microseconds to execute. My timing needs are an accurate as well as stable
> 1ms resolution clock, so I was confident at this point. 

> I tried to use ualarm(3) to execute a function every millisecond (ualarm let
> you set up any interval between 1 and ~65000 microsecond) and found out that
> the NeXT machine can't keep up with that speed and that for any interval
> smaller than ~65000 (the max, i.e. 65 ms), the process keeps losing
> interrupts. It's pretty OK for 60ms, or 30ms if I nice(1) the priority to
> -20 in superuser mode. I get better results too if the main program does a
> getchar(3s) instead of busy waiting.

I assume you are setting your alarms via absolute times.  If you continually
set an alarm for 1ms, you will add some small overhead (whatever it takes
you to set the next alarm) at each timer pop.

> Now, a quick comparison with the Comodore Amiga family will bring me to ask
> questions about NeXT and real-time:

> I have developped a lot of real-time software on the Amiga's operating
> system, and even the Amiga 500 (with a 68000) allows accurate 1ms timing in
> a multitasking environment. This proves that the NeXT's machine hardware
> should be able to handle such speeds, but Mach hides those capabilities
> completely. I believe this is due to virtual memory and paging. I think
> that NeXT has been working for two years on a real-time version of Mach, but
> hasn't come up with anything yet.

> I would expect much better real-time functions from a system that contains a
> DSP and great sound capabilities. This questions the NeXT machine's
> philosophy.

This demonstrates a common assumption that rarely bares out.  More powerful
machines arn't always faster (if ever) at real-time.  If you want real-time,
go buy a Z80 (or one of those Forth chips).  Look at the IBM PC.  While
Microsoft is busy creating a monster OS (OS/2), they have forgotten one very
important advantage of MS-DOS, that of its small size.  Sure, the new (large)
functionality set is neat, but it comes at a cost...

I live with this reality everyday.  Working for HP in their commercial-side
of the computer business, in order to increase "transaction throughput",
many infortunate compromises are made.  The most annoying is the lack of
usable character i/o.  Typeahead is a poor substitute.  VI on an HP3000 is
a joke!  Remember, bigger isn't always better.  Let's not condemn NeXT for
their compromise.  I'm sure they're working hard on lessening the impact
of providing all that functionality in a 1 cu. ft. box.

>             What does need more real-time than musical software ?

Real-time video...

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  Edward McClanahan
  Hewlett Packard Company
  Mail Stop 47UP              -or-     edwardm%hpda@hplabs.hp.com
  19447 Pruneridge Avenue
  Cupertino, CA  95014                 Phone: (408)447-5651