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