jcd@maps.cs.cmu.edu (Jean-Christophe Dhellemmes) (02/28/90)
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.
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.
In any case, those results are far from the accurate 1ms timing I am
expecting. I tried the same test programs on a very fast multiprocessor
machine, and even though Unix doesn't provide guaranteed low latency task
wake-up, I could go down to 500 microseconds without missing interrupts.
That is when the NeXT machine will be faster, I'll be able to do it.
I haven't used the 1ms timing facilities described in NeXT's Midi Library
documentation, and this is the next tests I am going to do. Anyway, Mach is
not a real-time system and in the current version will never guarantee that
you can execute a function in time. Virtual memory and paging are
high-priority kernel funtions and don't have a time limit for execution. So
I doubt the NeXT's Midi stuff will give a perfect answer to my problem.
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. What does need more real-time than musical software ? I can't
make use of the DSP and Midi on the NeXT machine, for me they are useless
without a real-time operating system, or at least some low level "hacks" to
do real-time work.
Would it be possible to catch "ultra-high-level" interrupts to implement
my own real-time kernel ? I am opened to any suggestions, including
solutions that will give me *practical* real-time capabilities, even if they
don't guarantee any time limit in the worst case.
I guess the people at NeXT read this netnews, and I am asking them what's
new to do real-time on the NeXT, and wether I can hope one day to develop
SERIOUS musical software on the NeXT.
* JCD
---------------------------------------------------------------------------
Jean-Christophe DHELLEMMES. e-mail (jcd@maps.cs.cmu.edu) (412-268-8801)
Carnegie Mellon University - School of Computer Science.
5000 Forbes avenue Pittsburgh PA 15213.
---------------------------------------------------------------------------clement@quiche.cs.mcgill.ca (Clement PELLERIN) (02/28/90)
In article <8196@pt.cs.cmu.edu> jcd@maps.cs.cmu.edu (Jean-Christophe Dhellemmes) writes: >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) An unsigned is 32bits on the NeXT. You can go up to 4 billion if you want, not just 64K. I tried a sample program and I could easily get signals at 1 second intervals.
jcd@maps.cs.cmu.edu (Jean-Christophe Dhellemmes) (02/28/90)
I wrote: > 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), ... Of course, this is wrong, an unsigned is 32 bits on the Next, so I could have done my test with higher values. Anyway, that's not the point, I am still interested in numbers much smaller than 1 second or even 65ms. Even the Amiga can do 1ms. * JCD -- --------------------------------------------------------------------------- Jean-Christophe DHELLEMMES. e-mail (jcd@maps.cs.cmu.edu) (412-268-8801) Carnegie Mellon University - School of Computer Science. 5000 Forbes avenue Pittsburgh PA 15213. ---------------------------------------------------------------------------
dandb@k.gp.cs.cmu.edu (Dean Rubine) (02/28/90)
>In article <8196@pt.cs.cmu.edu> jcd@maps.cs.cmu.edu (Jean-Christophe Dhellemmes) writes: >>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) In article <2285@quiche.cs.mcgill.ca> clement@quiche.cs.mcgill.ca (Clement PELLERIN) writes: >An unsigned is 32bits on the NeXT. >You can go up to 4 billion if you want, not just 64K. >I tried a sample program and I could easily get signals >at 1 second intervals. You're right to point out his mistake, but you've not helped him with his problem at all. He wants to get short intervals, not long ones. I've had success using DPSAddTimedEntry to get a function called every 20 msec. I haven't tried shorter times. Unfortunately, the only time the function gets called is when your process is waiting for input, i.e., these calls do not interrupt computation. For true real time control, you need at least the ability to bound response time to external events. For NeXT/Mach, presumably you'd want user level (not kernel) programs to operate in real-time, since this makes it possible for mere mortals to create such programs. This would mean the ability to lock a process in physical memory (since page faults must be avoided), to raise a process's priority so that it cannot be preempted, and to guarantee the time it takes to resume a process in response to some event (e.g. process X is guaranteed to be called within .5msec of such-and-such interrupt). All these things likely require pretty intensive Mach modifications, which is probably why they're not available (yet?), though I find the lack pretty inexcusable on NeXT's part. Like JCD points out, this makes the Amiga preferable for doing true real-time control work. -- ARPA: Dean.Rubine@CS.CMU.EDU PHONE: 412-268-2613 [ Free if you call from work ] US MAIL: Computer Science Dept / Carnegie Mellon U / Pittsburgh PA 15213 DISCLAIMER: My employer wishes I would stop posting and do some work.
garton@cunixa.cc.columbia.edu (Bradford Garton) (03/01/90)
In article <8196@pt.cs.cmu.edu> jcd@maps.cs.cmu.edu (Jean-Christophe Dhellemmes) writes: >Real-Time on the NeXT ? >======================= > >I haven't used the 1ms timing facilities described in NeXT's Midi Library >documentation, and this is the next tests I am going to do. This may work, as I understand it by using the Midi object in "timed" mode you are using a clock internal to the MIDI output driver. Similarly, I think that using the Orchestra in timed mode allows you to use the DSP clock for event timing. >Anyway, Mach is >not a real-time system and in the current version will never guarantee that >you can execute a function in time. Virtual memory and paging are >high-priority kernel funtions and don't have a time limit for execution. So >I doubt the NeXT's Midi stuff will give a perfect answer to my problem. This may be true -- I don't know at what level these clocks compete. >new to do real-time on the NeXT, and wether I can hope one day to develop >SERIOUS musical software on the NeXT. Does real-time necessarily == SERIOUS? I guess csound, cmix, et. al. are just for fun. Well, at least I think so! Brad Garton Music Dept; Columbia University brad@woof.columbia.edu
edwardm@hpcuhc.HP.COM (Edward McClanahan) (03/02/90)
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
hess@iuvax.cs.indiana.edu (Caleb Hess) (03/03/90)
NeXT has provided a way to get around at least some of the real-time problems of Mach. A Loadable Kernel Server can be installed with an option that keeps it from being paged, which is what you need for an interrupt handler. In fact, this is what the midi server does.
izumi@violet.berkeley.edu (Izumi Ohzawa) (03/03/90)
In article <680022@hpcuhc.HP.COM> edwardm@hpcuhc.HP.COM (Edward McClanahan) writes: >> What does need more real-time than musical software ? > >Real-time video... I have always wanted to know the following regarding the upcoming Color Board. Would anyone please leak the information to me? I promise to be discreet. I assume the Color Board has an independent graphics processor. Question 1: Does it have LUTs (Color look up tables) which can be refreshed during V blanking? Question 2: Would there be Timed Entries with guaranteed real-time performance for the graphics processor? The timings being locked to frame sync (V-sync). For example, is it possible to load LUTs every N frames guaranteed? I am not asking for Mach to do real-time, but wondering if the graphics processor can do some limited real-time syncronization. I am not asking for real-time graphics in Silicon Graphics-sense either. So, I believe the above are reasonable things one would want for a $5000 graphics system. Izumi Ohzawa, izumi@violet.berkeley.edu
cyliao@eng.umd.edu (Chun-Yao Liao) (03/04/90)
Has anybody thought about real time simulation? I guess a simulation that is not real time will be much useless. -- |I want Rocket Chip 10 MHz, Z-Ram Ultra II, UniDisk 3.5 | cyliao@wam.umd.edu | |I want my own NeXT, 50MHz 68040, 64Mb RAM, 660Mb SCSI, | Chun Yao Liao | | NeXT laser printer, net connection. | Accepting Donations!| /* If (my_.signature =~ yours) coincidence = true; else ignore_this = true; */