home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!cs4w+
- From: cs4w+@andrew.cmu.edu (Charles William Swiger)
- Newsgroups: comp.sys.next.hardware
- Subject: Re: New RISC workstations / 88110 demise
- Message-ID: <ceynlZy00WAy810IZ5@andrew.cmu.edu>
- Date: 6 Nov 92 17:47:49 GMT
- Article-I.D.: andrew.ceynlZy00WAy810IZ5
- References: <1992Nov2.170741.2092@jhunix.hcf.jhu.edu> <Bx5Iwn.to.2@cs.cmu.edu> <1992Nov5.070604.2071@cubetech.com>
- <BxBCpM.65B.2@cs.cmu.edu>
- Organization: Senior, Chemistry, Carnegie Mellon, Pittsburgh, PA
- Lines: 61
- In-Reply-To: <BxBCpM.65B.2@cs.cmu.edu>
-
- Excerpts from netnews.comp.sys.next.hardware: 6-Nov-92 Re: New RISC
- workstations /.. Doug DeJulio@cs.cmu.edu (975)
-
- >I'd buy this argument *IF* NeXT's OS had good realtime support.
- >However Mach 2.0 (upon which NeXT mach is based) is just not a
- >realtime OS, and you can't do realtime operations with it. User
- >interaction needs to be done by realtime tasks. That's the main
- >reason I was reccomending dedicated chips. No realtime means no
- >reliable synched animation and sound, which sucks on a multimedia
- >workstation.
-
- You can do reasonable realtime operations (such as animation) under the
- current Mach kernel (Version 2.6 on NeXTs, I believe). Try looking at
- the DPSTimedEntry stuff. There are examples from NeXT where at each
- frame, the animation code checks the actual time delay from the last
- frame, and generates the next frame accordingly. This means that the
- frame rate is not constant, but animated objects have constant velocity
- and could be sync'ed reliably with sound. This is generally acceptable
- if the CPU(s) can generate a reasonable frame rate considering the other
- loads on the system.
-
- But I can't argue that dedicating processing units (like the DSP for
- sound generation, or whatever) does not provide advantages for realtime
- processing, too.
-
- >If NeXT upgraded to Mach 3, perhaps they could get realtime
- >performance by running the display and sound servers at a higher
- >priority than the Unix emulation task, but in Mach 2 the unix
- >emulation is built into the Mach kernel so that can't be done.
- >Correct me if I'm wrong.
-
- "Unix emulation task"? What are you referring to? The Mach kernel does
- handle system traps (the functions described in "man 2 intro") for
- processes, exactly like any other kernel, and I don't see this changing
- under Mach 3.x. Mach provides these functions because a standard unix
- kernel provides these functions; programs written for another unix
- machine work on the NeXT without modification because the Mach kernel
- provides the exactly same functionality. This compatibility is one of
- the most important features of Mach.
-
- Admittedly, Mach implements things internally differently than most
- other unix kernels. For example, all IPC calls are implemented as
- special cases of a generic Mach message facility, where in other
- kernels, there are generally different internal structures used for
- pipes, semaphores, sockets, etc. Mach frees the programmer from
- worrying about which representation is most efficient (IMHO good). I
- have heard that Mach 3.x makes even more internal changes than Mach 2.6,
- which means that certain parts of the OS, like the terminal drivers,
- should be modified (for efficiency reasons) under Mach 3.x.
-
- But, so what? You seem to claim that Mach 3.x offers better support for
- realtime processing than Mach 2.6. I don't understand what information
- you're using to make this claim; please explain.
-
- -Chuck
-
- +---------------------------------------------+
- | Charles William Swiger -- CMU sucks rocks | "The television screen is the
- | AMS & normal mail: cs4w+@andrew.cmu.edu | retina of the mind's eye."
- | NeXTmail: <temporarily out of order> |
- +---------------------------------------------+ --Videodrome
-