Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!gargoyle!ihnp4!cuae2!killer!academ!uhnix1!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga,comp.sys.mac
Subject: Re: Multitasking: Amiga vs. Unix, and apple comments
Message-ID: <582@sugar.UUCP>
Date: Fri, 28-Aug-87 11:37:14 EDT
Article-I.D.: sugar.582
Posted: Fri Aug 28 11:37:14 1987
Date-Received: Sun, 30-Aug-87 08:58:30 EDT
References: <6565@eddie.MIT.EDU> <2742@hoptoad.uucp> <3638@cit-vax.Caltech.Edu> <56@stb.UUCP>
Organization: Sugar Land UNIX - Houston, TX
Lines: 79
Summary: That's not what nice is for.
Xref: mnetor comp.sys.amiga:7910 comp.sys.mac:6153

In article <56@stb.UUCP>, michael@stb.UUCP (Michael) writes:
> Someone asked for an explanation of why Amiga's multitasking system is
> better than unix's, and made the comment about poor performance for
> interactive programs on unix, esp. on demand paging.

It's not better. It's different. UNIX is optimised to give good response
time to a large number of interactive terminals. The Amiga's scheduler
is optimised to give immediate response to real-time events. The Amiga
is not a multiuser system, and probably can't be. UNIX is not a real-time
system, but you can change the scheduler to make it one. AT&T uses real-time
UNIX all over the phone system.

> #1. Priority.
> Unix goes out of its way to give everyone sometime unless the system is totally
> hogged.

which is what you want in a timesharing environment, and isn't too bad in a
low-grade real-time one.

> Amiga, in contrast, has fixed priority levels--if you are at a higher
> priority, you get all the time you want. Basically, its like saying "Nice jobs
> finish last, er, niced jobs get no time unless no one else wants it", as
> opposed to "Niced jobs get 80% of what they would have".

I'd rather have niced jobs get 80% of expected time. That's what nice is for...
to allow you to be nice to other users without keeping your job from
running at all. Nice is for CPU hogs who want even less of the system than
they would normally get.

> #2. Demand paging.
> This is good only for one thing: Letting a large program run on a small machine.
> If an interactive program has to wait while a background task runs and pages
> in, that program is very slow.

Because of the transparent asynchronous I/O shared by the Amiga and UNIX,
paging in another program does not make you wait. The only time you have
to wait for paging is when you're the one being paged. Isn't that better
to not being able to run at all?

> The Amiga does not suffer from this mixed blessing.

If you never run more programs than you have memory, the overhead for a paged
system is miniscule. If you need to run more programs than you have memory,
isn't it better to have the option?

If they don't get in your way, having more options is never a defect.

My personal experience is that UNIX pages quickly and unobtrusively in a
lightly loaded environment. You obviously have used a heavily loaded system.
UNIX handles increasing load in such a nice way that there is this tendency
to just keep pouring on the users. It's like an Italian 12-cylinder engine:
there always seems to be more RPM out there. Unfortunately, computer centers
don't have RPM limiters.

> The Amiga does not swap, so it can give good response time.

UNIX does not swap (or page) under the same circumstances. Try playing with
an AT running Microport System V with 5 MEG of RAM some time.

> programs get CPU time, even when niced. I've had programs run at nice
> of +20 on non-paging systems (they run just fine when other people are
> doing disk io, and they still get good time on their own IO), even when
> I put them there because I wanted them to WAIT.

That's not what nice is for. The best way of getting a UNIX program to wait
when it's not expecting to have to is to convince it to read from your
terminal. Or switch to BSD UNIX and send a SIGSTOP.

> What we need is a "nice"'ing scheme sort of in the middle, where a little
> niceness does make a noticable difference in performance, and also 
> in I/O speed. But at the same time, if you get a signal/message/whatever,
> you should be guaranteed CPU time quickly to respond to it.

This is basically what UNIX gives you. Its just that UNIX does such a
good job of resource *sharing* that even a major drop in priority doesn't
stop you dead in your tracks.
-- 
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter
--                  U   <--- not a copyrighted cartoon :->