Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!cit-vax!elroy!mahendo!jplgodo!wlbr!scgvaxd!stb!michael From: michael@stb.UUCP (Michael) Newsgroups: comp.sys.amiga,comp.sys.mac Subject: Re: Multitasking: Amiga vs. Unix, and apple comments Message-ID: <93@stb.UUCP> Date: Mon, 31-Aug-87 11:36:26 EDT Article-I.D.: stb.93 Posted: Mon Aug 31 11:36:26 1987 Date-Received: Sat, 5-Sep-87 04:25:39 EDT References: <6565@eddie.MIT.EDU> <2742@hoptoad.uucp> <3638@cit-vax.Caltech.Edu> <56@stb.UUCP> <582@sugar.UUCP> Reply-To: michael@stb.UUCP (Michael) Organization: STB BBS, LA, CA, USA, 90402, (213) 459-7231 Lines: 117 Xref: mnetor comp.sys.amiga:7991 comp.sys.mac:6241 In article <582@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <56@stb.UUCP>, michael@stb.UUCP (Michael) writes: (me) >> 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 No, unix is optimized to give good throughput on CPU hogs and resonable interactive response time for lightly loaded systems. If you've modified your scheduler/swapper/pager, then this may differ. >> #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. Not if you want interactive tasks to get more priority (which I do) >> 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. Niced jobs get 80% of if they were not niced. I'd like to see that figure lower, say 25-30%. >> #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? What I meant was, the interactive task stops for I/O, gets swapped or paged out, and then has a slow swap in. And on my system, when the swapper runs, NO ONE ELSE gets any I/O to that device. Since my /dev/swap is permenently on the end of /dev/root, that means any access to /bin or /tmp gets blocked. >> 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. The Hardware support for paging is a 10% overhead even when you don't need to page. This is the overhead for the TLB (Tomato, lettuce, bacon) (Translation lookaside buffer) which is a cache for storing the address translation table. >My personal experience is that UNIX pages quickly and unobtrusively in a >lightly loaded environment. You obviously have used a heavily loaded system. Yes, I've used UCLA and a home computer (68000, 512K originally, now 1meg.) >> 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. Gee, if only I could get 5meg on my system. But it was designed in 1982. >> 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. Does anyone make BSD for a TRS-80 16? I didn't think so. But I can't modify programs I didn't write, and I will not modify a program that normally doesn't need I/O too need I/O. >> 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. Let me try again: If you have 4 CPU hogs, a niced (+5) job will never run. If you have 3 CPU hogs, a niced (+20) job will never run. If one of those 3 decides to do I/O, the niced +20 job will swap in and swap it out. Suddenly, your interactive speed drops to the speed of trashing. Incidently, if a job is niced +20, and 3 CPU hogs exist, that niced job will never see a signal. Not even a kill -9. Michael Unix quotes are based on a V7 swapping system with 512K memory. 1meg on sys3 helps, but not much (I still swap even when only 400-600K of my 870K user memory gets used.) -- : Michael Gersten seismo!scgvaxd!stb!michael : Copy protection? Just say Pirate! (if its worth pirating)