idallen@watmath.UUCP (11/10/84)
> From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) > > [That UNIX does not do real-time stuff well] is an old myth based partly > on fact. > > [List of drawbacks was here.] > > All these drawbacks can be overcome by a competent UNIX system programmer. But is what you get after all those hacks still UNIX? Someone posted a simple "fix" to a "bug" in Berkeley Pascal involving a missing "default" in the CASE statement, and the cries went up that the resulting language was no longer "Pascal". Interesting point. How much UNIX can you hack up and still call it UNIX? An interesting question, but not the central point I want to make. UNIX can do anything if you just rewrite this or that. The same applies to any piece of software -- if you rewrite it, it can do anything. I guess people who pose questions about what UNIX can do have to be more explicit when they ask. For example (hypothetical): I have a binary multi-user UNIX 4.2bsd. Can *my* UNIX do real time stuff nicely? (Answer: No.) I now have an old V6 UNIX with source code. Can *my* UNIX support virtual memory? (Answer: Yes. Just have a competent UNIX system programmer overcome this drawback by modifying the kernel.) When one says X supports Y after {one,six,twenty} man-months of rewriting, is that a fair answer? I think not. I think a fair answer would say "No, X doesn't support Y, but if you want to spend N weeks changing X, *you* can create *your own* version of X that supports Y." -- -IAN! (Ian! D. Allen) University of Waterloo
dmmartindale@watcgl.UUCP (Dave Martindale) (11/10/84)
> How much UNIX can you hack up and still call it UNIX? An interesting > question, but not the central point I want to make. > > UNIX can do anything if you just rewrite this or that. The same > applies to any piece of software -- if you rewrite it, it can do > anything. UNIX means different things to different people. To old-time UNIX hackers, UNIX is any operating sytem which started out from the Bell code and still has somewhat the same flavour to it. (When was the last time you saw an unmodified UNIX kernel on any site with source and a guru, anyway?) Certainly most of these modified kernels were closer to the original UNIX than they were to RSX or CPM or whatever, so why not still call them UNIX? So, to this group, UNIX is a set of ideas more than any specific piece of code. Of course, when people ask "can UNIX do real time?", they probably mean a version of unix they can buy off someone's shelf, and don't have to modify themselves - a different definition entirely. Maybe we should start referring to the "UNIX family of operating systems"?
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/12/84)
> > [That UNIX does not do real-time stuff well] is an old myth based partly > > on fact. > > > > [List of drawbacks was here.] > > > > All these drawbacks can be overcome by a competent UNIX system programmer. > > UNIX can do anything if you just rewrite this or that. Anyone doing real-time programming has to write some nitty-gritty stuff. My point was that it is no harder to do this on UNIX than on any other system (e.g., VMS). The actual kernel changes alluded to amounted to (a) addition of a plock() call, now standard in UNIX System V. (b) addition of a real-time queue in the scheduler. (c) provision of a smart device driver for the A/D interface. I did (a) and (b) in a matter of hours. (John Quarterman showed me how to do (a) with very little effort.) A preliminary version of (c) was done by someone else and rewritten by Quarterman in a few days, along with the matching user-mode double-buffered data acquisition process. These are hardly major changes to UNIX, nor is it unreasonable to ask that the real-time implementor do a bit of work like this. It would certainly be nice if future UNIXes would provide strict priority scheduling and perhaps the 7th Edition phys(2) call to make it even easier for the real-time programmer. It would also be nice if the overly conservative critical region locking in the kernel were replaced by semaphores (I think the 3B20A UNIX kernel has this) for finer control of interrupt latency. Anyone who tries to develop a significant real-time application without the means to fix problems caused by the operating system implementation is asking for trouble. Anyone who thinks he is going to get good real- time response on a timesharing system without a bit of work is a fool.
henry@utzoo.UUCP (Henry Spencer) (11/13/84)
Furthermore, anyone who thinks that manufacturer X's Wonderful Realtime
Operating System is going to do *exactly* what he wants is dreaming.
Real-time applications vary too much; the user (or his programmer) is
going to have to write some code no matter what he does. Doing this
for Unix is no harder than doing it on other systems.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryshannon@sun.uucp (Bill Shannon) (11/13/84)
To most people, real-time means guaranteed maximum response time to interrupts. With UNIX's use of spl's to provide critical sections, it is hard enough just reducing the time spent at high priority, let alone guaranteeing that you'll only be at high priority for some maximum time considering all the possible unanticipated combinations of critical sections calling critical sections being interrupted by higher priority devices calling who knows what. Everyone has to cooperate to keep the interrupt response time as low as possible. Right from the start UNIX is not cooperating. A good example of real-time requirements in many newer UNIX systems is being able to handle 9600 baud asynchronous input with little or no hardware buffering. On the Sun our approach to guaranteeing that we could service the interrupt as soon as possible was to make the UARTs interrupt at a priority higher than the system used for anything else, even the clock. The interrupt routine does the absolute minimum amount of processing, just reading the character and saving it away in a buffer in memory and triggering a software interrupt at a lower priority to actually process the character. VMS takes a similar, but more general, approach to the problem. On VMS the interrupt routines save away only the absolute minimum amount of state for the device and reschedule a lower priority "process" to handle the interrupt. It's often possible to construct a special version of UNIX to solve a specific real-time problem but it's much more work to restructure the system so that a general solution to a whole class of real-time problems is possible. Bill Shannon
geoff@desint.UUCP (Geoff Kuenning) (11/18/84)
In article <5727@brl-tgr.ARPA> Doug Gwyn <gwyn@brl-tgr.ARPA> writes: >Anyone doing real-time programming has to write some nitty-gritty stuff. >My point was that it is no harder to do this on UNIX than on any other >system (e.g., VMS). Adding real-time support to VMS is precisely as hard as adding pipes to Unix-- it's already there. As to adding real-time to Unix, see the comments by Bill Shannon from Sun Microsystems about spl()'s. The fact is that Unix is so bad at real-time performance that most micro-based Unixes can't handle even *one* 9600-baud incoming data line, though even an 8080 has the power to handle two. -- Geoff Kuenning First Systems Corporation ...!ihnp4!trwrb!desint!geoff
geoff@desint.UUCP (Geoff Kuenning) (11/19/84)
In article <4630@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >Furthermore, anyone who thinks that manufacturer X's Wonderful Realtime >Operating System is going to do *exactly* what he wants is dreaming. >Real-time applications vary too much; the user (or his programmer) is >going to have to write some code no matter what he does. Doing this >for Unix is no harder than doing it on other systems. Gee, Henry, I worked on a 5-person-year project running under RSX-11M, and the only mods I had to make to the OS were the installation of drivers for our optional hardware. I know of many, many, many other cases where a real-time application was written successfully under a manufacturer's OS without making modifications. The obvious example is VRTX, which comes in ROM (though, to be fair, you have to add a lot of drivers). But I have seen this done on operating systems from DEC, IBM, Intel, and many others. I might believe that UNIX/RTR for the 3B20S, or DMERT for the 3B20D, is a reasonable real-time operating system. (I haven't had a chance to read the BSTJ on them yet.) As has been pointed out before, there is nothing in the UNIX system call repertoire that requires non-real-time code in the kernel. (Although there are *many* missing features, such as asynchronous I/O, that real-time programmers would consider necessary). But UNIX/RTR is available only for the 3B20 as I understand it, and ordinary UNIX is a long way from being usable for real time. Bill Shannon's excellent discussion of interrupt latency covers one of the biggest, though not the only, reasons. If the "real-time" task that you want to perform involves replacing your wall thermostat with your computer, a PC running UNIX with a load average of 80 is probably sufficient. The response-time requirements just aren't that large. In fact, you can come up with hypothetical control applications (lighting control for a greenhouse, perhaps?) slow enough to run on a batch machine. The things that make a real-time operating system real-time are twofold: low and predictable overhead, and a complement of system services that serves the needs of the real-time applications programmers (an excellent summary of the latter can be found in the ISA standard for process control; UNIX System V provides many but not all of the required functions). Yes, all of these features can be added to UNIX with some effort. That means it can be turned into a real-time operating system, not that it already is one. -- Geoff Kuenning First Systems Corporation ...!ihnp4!trwrb!desint!geoff
Mike Gallaher <Gallaher@RU-BLUE.ARPA> (11/20/84)
From: Bill Shannon <shannon@sun.uucp> [handling] 9600 baud asynchronous input with little or no hardware buffering. On the Sun our approach to guaranteeing that we could service the interrupt as soon as possible was to make the UARTs interrupt at a priority higher than the system used for anything else, even the clock. I've suspected for a while that that is the reason why the time of day clock on our Sun 120 loses up to an hour or more a day, depending on "system activity", which turns out to be "serial port usage". We have two 9600 baud ports and a 1200 baud uucp port. The hardware clock is accurate, but the system time is set by it only at boot time. mike gallaher ....!sun!sunrise!unipress!mg mg@rutgers -------
hamish@elecvax.OZ (Hamish Reid) (11/23/84)
>> > [That UNIX does not do real-time stuff well] is an old myth based partly >> > on fact. >> > >> > [List of drawbacks was here.] >> > All these drawbacks can be overcome by a competent UNIX system programmer. >> >> UNIX can do anything if you just rewrite this or that. > Anyone doing real-time programming has to write some nitty-gritty stuff. > My point was that it is no harder to do this on UNIX than on any other > system (e.g., VMS). ... ...And MY point would be that for someone in my position, with a binary Level 7 Unix License, it is actually INFINITELY harder 'to do this on UNIX than on other systems..' - eg RSX-11, on which I can expecte and get true priority scheduling, guaranteed real-time delays and time-outs, etc, etc... all without ANY mods to the kernel Now RSX may be the Unix guru's idea of the canonical bad operating system (and I'd have to agree) but our real time work simply can't be done on any of the Unix's I have shopped around for, without very expensive hacking at the kernel - which we can't do with a binary license - and which is not needed with, say, RSX... > > These are hardly major changes to UNIX, ... ...again, they ARE if you have a binary license, and "support" from your average vendor - and anyway, this just re-raises the "what is Unix" question again - Unix will definitely SUPPORT the DEVELOPMENT of real-time systems, which can then run on a more supportive system (I just dream of an RSX-Unix cross development system...), but none of the Unices available to my organisation would support the r/t system already running on our RSX machine. I think it is about time people realised that MOST Unices of the future will be binary licenses, and that to try to make "Unix" cover all grounds is a little pointless.... Hamish Reid ...!decvax!mulga!hamish:ipso Ionospheric Prediction Service, Sydney, Australia