Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ptsfa!hoptoad!academ!uhnix1!nuchat!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: <629@sugar.UUCP> Date: Thu, 3-Sep-87 07:01:14 EDT Article-I.D.: sugar.629 Posted: Thu Sep 3 07:01:14 1987 Date-Received: Sat, 5-Sep-87 17:46:39 EDT References: <6565@eddie.MIT.EDU> <2742@hoptoad.uucp> <3638@cit-vax.Caltech.Edu> <93@stb.UUCP> Organization: Sugar Land UNIX - Houston, TX Lines: 137 Summary: I'm sorry that your trash-80 has soured you on UNIX Xref: mnetor comp.sys.amiga:8079 comp.sys.mac:6349 In article <93@stb.UUCP>, michael@stb.UUCP (Michael) writes: > In article <582@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >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. That's an interesting statement, given that the whole design of the UNIX scheduler is oriented towards giving good throughput on a large number of interactive terminals. It also gives adequate response time. > >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) Interactive tasks do get more priority. If a process does not use all of its time slice, it's priority is raised. Interactive tasks don't tend to use all of their time-slice. > >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%. Why? I really don't understand your point here. If they can still run 80% of the time they would otherwise (presumably because your task is waiting on I/O), why shouldn't they? > >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. OK. That's a different matter. Still... isn't that better than not being able run at all? If not, why did you start that CPU-hog in the first place? > 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. Your system is a TRS-80 model 16. I evaluated that machine and decided that it was basically inadequate for real work because of poor hardware design and bad choices in the UNIX port. I don't recall if this was part of the poor choices, but I wouldn't be surprised. > >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. Always a flat 10%, right? If the memory is fast enough the CPU will see no overhead. After all, the Amiga has up to a 100% overhead for the custom chips... you just don't see it because it's going on when the CPU couldn't use the bus anyway. > >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.) A 68000 with a meg should be a pretty lightly loaded home computer. We used an LSI-11/23 with a meg. The LSI-11/23 is by no means as fast a processor as the 68000. Yet, unless someone was doing a virtual link the response time was very good. > >> 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. OK... try running your system with no more programs loaded than will fit into memory. This should effectively mimic an Amiga with a Meg. Then decide whether you would rather have the option of running another program at a lower speed or not. > >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. Put a little routine in to catch signal 16 and wait until it's gotten another signal. Then, when you want it to wait do a "kill -16 ". Do I have to do all your thinking for you? It shouldn't be too difficult to patch in the extra instructions to do this. Then do a "#define SIGSTOP SIGUSER1" > 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. Typically, your CPU hog is the one you want to nice. So, why are you running more than 1 CPU hog on a trash-80? Your problem is that you're way overdriving your machine. Version 7 is normally a very nice operating system. Much more comfortable in small quarters than any other I've ever used. Once again... UNIX has fooled you into thinking it will always be able to take on more work. Unfortunately... in the real world... that ain't the case. > 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. At least until the CPU hogs do I/O. Why aren't you nicing the hogs? > 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.) You don't have system 3. Xenix is based entirely on version 7. Microsoft added a bunch of stuff to make it look like S3. Also, the TRS-80 model 16 has a totally inadequate MMU, which is possibly why you're seeing it swap so easily. They probably put in a lot of firewall space to allow for the lack of hardware memory protection (!). I'm sorry you got stuck with the machine you did. What are you using it for, maybe I can make suggestions to improve its performance. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- U <--- not a copyrighted cartoon :->