Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!thor!pcg From: pcg@thor.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.i386 Subject: Re: How many users _really_ ? Message-ID: Date: 25 Aug 89 20:42:04 GMT References: <1045@aber-cs.UUCP> <32824@apple.Apple.COM> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 74 In article <32824@apple.Apple.COM> leech@Apple.COM (Jonathan Patrick Leech) writes: >In article <1045@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >>Agreed. In most light applications, i.e. o.a. or general timesharing, at any >>one time 1/10th of the users are running a process. A Vax 11/780, which is a >>much less powerful machine than a suitably configured 386, could easily run >>two dozen (and three dozen with some effort) users doing small compiles >>etc... > Only if you *like* waiting 5 minutes for "hello.c" to compile, or >several seconds for screen updates (at 4800 baud, yet). We had a 780 >as the main student machine at Caltech some years back, and it could >not comfortably handle more than 10-15 users or so. Between comfortable use at the 10-15 users level and at the two dozen user level there is a world of difference, i.e. suitable configuration (always assuming that no large jobs are run, e.g. tex/lisp/gnu etc...). Using the 10% rule, with 10-15 users one is likely to see maybe 1-2 processes active at one time, with two dozen it is more likely 2-3; not a terribly big difference. The real difference TO RESPONSE TIME lies in the io configuration. If you have a single disc, or a single data path to peripherals, a lot of full screen edits with dumb (i.e. silo/fifo less) serial lines, too little buffers, then a 780 is on its knees even before the 10-15 users mark. Adding a second disc, raising the buffer cache to 20-25% of memory (e.g. 1-2 megabytes), enabling pseudo dma or installing intelligent serial lines, having /tmp not on the same disc where users file are, and swap/paging on the disc not where the root and /usr are, make a big big difference. If you have independent data paths for your discs (e.g. a MASSBUS one and a UNIBUS ones) things get that much better (using 4.3 instead of 4.2 and 4.2 instead of 4.1 of course improves things again). The same is true, with adjustments, on a 386. A 386 with one 300 meg drive is MUCH slower than one with two 150 meg ones, preferably on a multithreaded controller (e.g. AHA154x) or on two single threaded controllers, especially if the disc partitioning is done ok. On a 386 it is also important to ensure that there is enough real memory that swapping never occurs, even if this means a huge (huge!) waste of the commodity, as the system V swap algorithms is badly, badly brain damaged (in particular expansion swaps), even if paging ought to alleviate the occurence of the problems. With many users, cpu times are not that important, or at least not as important as I/O (especially to temporary files and swap) latency and overhead. Too bad that the default configurations of almost all commercial systems are badly detuned (notably SUN's, by the way). I have seen many a UNIX system or network (not to speak of MVS, VMS, EXEC, etc...) running at a fraction of their potential load because of obviously poor tuning. There is a problem also that many UNIX algorithms are simply unsuitable for today's large machines; one famous case is the beautiful BSD's `clock' page replacement algorithm, that was carefully designed for performance, ON A 512K SYSTEM (the original ucbvax). Too bad that on a machine with several megabytes the `clock' sweep may now take *minutes*, thus making it essentially useless... Similar is the case of the system V swap algorithm, as already noted. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk