peter@sugar.hackercorp.com (Peter da Silva) (11/13/89)
This message is only tangentially relevent to the Amiga, and the chain is likely to veer off into a UNIX vs realtime discussion. I'm directing followups to comp.realtime, where there is likely to be more light and less heat. In article <22175@gryphon.COM> bagpiper@pnet02.gryphon.com (Michael Hunter) writes: > peter@sugar.hackercorp.com (Peter da Silva) writes: > >UNIX is not real time. Many of the things we now take for granted would just > Now Now Now...not quite so hasty. There are extensions to Unix' that make > doing real time work easier. I know. I'm in the SCADA business. None of the extensions that make UNIX real time are generally available. Apparently V.4 will have a preemptable kernel, and that's a start. But it's not enough: a task can still be indefinitely deferred by swapping, UNIX floating priorities, etc. It's possible to build a realtime system that looks like UNIX, but Commodore does not have the resources to do this. > I think your following comments are more along > the lines of Unix has more overhead then Intuit. [I presume you mean AmigaOS] No. There is more to realtime than performance. You can do realtime work on a Cosmac 1802 (almost a 4-bit machine) at 500 KHz. A realtime problem is one in which if an answer is late, it's wrong. Music, for example, is realtime. If a note is late, you've blown it. I suspect you're thinking of the NeXT here, which has been used for music demos. Given enough MIPS, a simple enough problem, and a controlled environment, you can get close enough to realtime for a canned demo. But you've heard what happens to some poorly written music programs on the Amiga when you start excersising the blitter? In UNIX, that sort of thing can go on at arbitrary intervals, and the sorts of things you have to do to make a program real-time aren't possible. > which is very true. But it > also is more portable (even BSD to ATT) then any set of micro OS. This is true but irrelevant. A helicopter is more mobile than a car, but it is also prohibitively expensive for individuals. A real-time UNIX would be wonderful, but there's nobody who can afford to do one for a low-end machine. > A curious though that just came to mind is that Ada is suppose to be part of > the POSIX standard....Ada is (suppose to) react to certain real time stimili > so I think that implies that POSIX will be able to be used for real time > tasks...??? ADA is NOT a real-time system. ADA is a language with certain real-time concepts built in. I've done most of my real-time work in Forth, Fortran, PL/M, and C. All of these languages can be used for real-time work. But running under a non-real-time O/S it's just another language. > Personal gripe: The acronym MIPS has no real hard meaning. It is a relative > measurement that is not relative to anything easily tied down.... I'm using commonly accepted VAX MIPS ratings, based on the latest Dhrystone benchmark. That solid enough for you? -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' "IT'S THE TWO GODDAMNED CULTURES AGAIN !*! Bit-brained nerdery on one 'U` side, effete fin-de-siecle malaise on the other. And kingdoms of hybrid delight abandoned in the middle." -- burns@latcs1.oz (Jonathan Burns)
ford@amix.commodore.com (Mike "Ford" Ditto) (11/14/89)
In article <4532@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >UNIX is not real time. Many of the things we now take for granted would just >not be possible under UNIX, or would be unbearably slow. It would kill the >Amiga as a platform for MIDI (and music in general), animation, games, and >other real-time applications. Window and screen updates would slow down by a >factor of 10 (a 25 MHz 80386 under X is less responsive than a 7 MHz 68000 >under Intuition, and it's about a 5 MIPS machine instead of a .7 MIPS one). Everything in the above paragraph is false. Peter doesn't seem to know a trademark from an operating system implementation. There are many things commonly called "Unix", and even the ones to which the trademark actually applies are widely varied and evolve over time. Apparently Peter has never seen one which meets his expectations of a real-time system, and has concluded that if he has not seen it, it can not possibly exist. Ever. "Unix", as people (except Peter) seem to be using the term here, refers to a fairly abstract model of multitasking, and a set of programmer interfaces to it. It typically also implies a set of tools and user interfaces in the form of a set of programs. None of these notions have any relation whatsoever to real-time performance. The details of process scheduling have never been specified as part of any standard AT&T Unix release, although there have been many variations with custom scheduling algorithms designed for particular purposes such as real-time processing. "Unix" and "real-time" are orthogonal concepts. You can have either one without the other, or neither, or both. With AmigaDos we technically have neither, although we are close enough on both sides to do some good things. With a particular implementation of Unix, real-time capability might or might not exist. In article <4537@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <22175@gryphon.COM> bagpiper@pnet02.gryphon.com (Michael Hunter) writes: >> Now Now Now...not quite so hasty. There are extensions to Unix' that make >> doing real time work easier. > >I know. I'm in the SCADA business. None of the extensions that make UNIX real >time are generally available. Apparently V.4 will have a preemptable kernel, >and that's a start. But it's not enough: a task can still be indefinitely >deferred by swapping, UNIX floating priorities, etc. In System V, even as far back as release 2, processes are only deferred by swapping if they have not requested to be locked in physical memory. SVr4 does not have a preemptable kernel; it has a real-time process scheduler in its list of scheduling classes from which a process can choose. "Unix floating priorities" only apply to processes in the "time sharing" class, not in the "real-time" class. >It's possible to build a realtime system that looks like UNIX, but Commodore >does not have the resources to do this. If you mean there aren't enough programmers here to implement a real-time OS from scratch in this decade, you're probably right. But Commodore has other resources; for example such a system could be licensed. I won't go so far as to claim that SVr4 will meet Peter's demands for a real-time system because I haven't tried the real-time support nor even examined it closely, but my point is that the term "Unix" implies *nothing* about real-time performance. For someone who wants a real-time system, they should reject particular OS implementations which do not meet their needs, not an entire class of systems with many other appealing properties. > But you've heard what happens to some poorly written music >programs on the Amiga when you start excersising the blitter? In UNIX, that >sort of thing can go on at arbitrary intervals, and the sorts of things you >have to do to make a program real-time aren't possible. Yes, some system facilities to control the real-time properties of processes are necessary. Unix happens to be known for its ability (and tendency) to have new factilies added. SVr4 has them. (I am refering to current beta releases, of course, I can't predict what will actually be released.) -- -=] Ford [=- "Only Nasatine offers (In Real Life: Mike Ditto) fast-acting Mucanol" ditto@amix.commodore.com uunet!cbmvax!ditto ford@kenobi.commodore.com
nigel@modcomp.UUCP (Nigel Gamble) (11/16/89)
in article <104@amix.commodore.com>, ford@amix.commodore.com (Mike "Ford" Ditto) says: > "Unix" and "real-time" are orthogonal concepts. You can have either > one without the other, or neither, or both. With AmigaDos we > technically have neither, although we are close enough on both sides > to do some good things. With a particular implementation of Unix, > real-time capability might or might not exist. A realtime UNIX operating system does exist! It is called REAL/IX and it is MODCOMP's port of System V R3. It runs on MODCOMP's 68030-based 9700 series. It is fully compatible with the standard Motorola port of UNIX SVR3 (it will run Motorola UNIX/SYSV68 binaries), but it has a fully preemptive kernel and all the other necessary attributes of a realtime o/s. (MODCOMP, with its proprietary operating system MAX, has been in the realtime business for 20 years). Perhaps Commodore should licence REAL/IX for the Amiga? -- Nigel Gamble "Everything should be made MODCOMP an AEG company as simple as possible, but 1650 W McNab Rd, Ft Lauderdale, FL 33340-6099 not simpler." A. Einstein uunet!modcomp!nigel
doug@xdos.UUCP (Doug Merritt) (11/21/89)
In article <104@amix.commodore.com> ford@amix.commodore.com (Mike "Ford" Ditto) writes: >If you mean there aren't enough programmers here to implement a >real-time OS from scratch in this decade, you're probably right. But >Commodore has other resources; for example such a system could be >licensed. Yes. For instance, Lynx OS (Campbell, CA) looks like it might be a good candidate. They rewrote the kernel from scratch to support real time issues, and it apparently conforms to reasonable Unix standards documents (let's not get sidetracked into discussing how "standard" such things are) and claims to run unmodified Unix binaries. I've felt for years that this is the right way to go; the lack of real time facilities in (commonly available/standard) Unix's is aggravating in the extreme even when implementing normal applications. This is usually most visible to folks who implement games on Unix, or to people who are used to facilities like that on the Amiga, or even on (gasp!) the IBM PC (not that it's got "nice" real time facilities, but its sheer primitive and non-multitasking nature allow people to write real time code). Disclaimer: all I know about Lynx is what I've read in their own brochures. >Yes, some system facilities to control the real-time properties of >processes are necessary. Unix happens to be known for its ability >(and tendency) to have new factilies added. SVr4 has them. That's great news; I hadn't heard this before. That'll certainly help us (at Hunter) in creating more responsive applications with less system overhead. Some of the things we've had to do on Sys V (and even Sun/BSD) are pretty yucky: "well, it got the job done, but wish there was a better way!" Digression: AmigaDOS, of course, makes most such real time programming problems far easier to solve. But as has been pointed out numerous times, AmigaDOS has its own faults. And I'm still trying to figure out how to make my Amiga have as nice of a programming environment as my Sun. Kind of wierd...in many ways it has the potential of being better (lack of memory protection aside), but I dunno...maybe I just haven't gotten the right software together here? If anyone out there (with solid Sun experience as a point of comparison) has put together a development environment on their Amy that they prefer *overall* (not just in little areas), I'd like to hear about it. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary