Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.micro.68k Subject: Re: 68vs86 (flame?) Message-ID: <2350@sun.uucp> Date: Wed, 26-Jun-85 04:46:16 EDT Article-I.D.: sun.2350 Posted: Wed Jun 26 04:46:16 1985 Date-Received: Fri, 28-Jun-85 00:42:10 EDT References: <253@kontron.UUCP> <2328@sun.uucp> <260@kontron.UUCP> Distribution: net Organization: Sun Microsystems, Inc. Lines: 56 > > (I have one window monitoring mail, one displaying the current time, one > > displaying a graph of CPU utilization, one remotely logged in to "sun", > > one waiting to remotely log into another machine, and another one giving > > a shell on my own machine.) > Notice that most of what you point out as the desirable qualifies as simple > monitor tasks. Almost isn't good enough. Right now, the shell remotely logged in to "sun" is active, and the shell on my own machine is semi-active - earlier today it was *quite* active recompiling a kernel while this one was also logged in to "sun" while I was reading my news (reading news while waiting for a compile to finish is sort of like reading while sitting on the... well, you know). If the compile stopped for some reason, I could switch my attention relatively quickly to the other screen. > And at that you are obviously aware of how much "horsepower" > these tasks take up - you run a utilization monitor. Yes, I am. They take up a negligible amount of time. The only monitoring tasks are the clock, the mail monitor, and the CPU monitor. The mail monitor checks every 5 minutes, so it's not consuming much time. On an idle machine the CPU time graph is flat at 0% (i.e.,%) - that's *with* both of those monitoring tasks running. The shells, when idling, don't take up any CPU resources at all. The resource that's really eaten up by all this stuff is swap space (4.2BSD's profligacy with swap space has been much discussed in net.unix-wizards, but that's another topic). > I have no doubts that such systems will be the "wave of the future", but > if I can't turn it off when I want my machines full attention on something > I consider important, I'd rather not have it. [ Personal peeve ] Definitely personal; I'd go batty on a single-tasking system no matter how fast it was, unless it was *so* fast that I never had to wait for it to complete any of the tasks (and even then I'd sorely miss having multiple windows). If your task is *so* CPU-bound and *so* time-critical that the machine can't do *anything* else while it's running, there are a number of possibilities: 1) somehow putting the task outside the reach of the scheduler and giving it direct access to all the resources it needs (i.e. running it either as a specialized part of the OS kernel or as a peer of the OS kernel) 2) dedicating a special processor to the task (Masscomp uses this approach for high-speed data acquisition; I think they claim the ability to sample at 1MhZ which is difficult, at best, with *any* general-purpose processor - a 1 MIP processor would have to execute one instruction per sample...) Otherwise, as long as your OS permits reasonably direct access to the resources a task needs, and has a scheduler that requires minimum overhead if all the "time-sharing" tasks are blocked or running at a worse priority than your real-time task (and doesn't try and time-slice the real-time tasks), a multi-tasking OS is probably good enough. Guy Harris