jeff@swusrgrp.UUCP (Jeff Tye) (07/05/89)
In article <14760@watdragon.waterloo.edu>, hjespersen@trillium.waterloo.edu (Hans Jespersen) writes: > > How many CONCURRENT users ( of typical office automation software ) > can you respectfully support on a '386 PC ? I know this is vauge and > will vary considerably depending on the configuration but anyone want > to give it a shot ? I have customers that support 30 users. How do they do it? 1) Lot's of memory. 16MB at least or if the BIOS supports it, more. 2) Intelligent I/O cards for serial ports. Try the Corollary 8X4 mux card or the SpecialX mux card. Both offer exceptional performance. Strive to balance the load amongst the cluster boxes. Use a mux card that *supports* CPU caching. And research your vendor before taking the plunge. 3) Above all else, install the DPT caching disk controller with 8MB or more of disk cache. It really works. Disk I/O is the biggest bottleneck in AT class machines. 4) Tune, tune, tune, that kernel. Layout your disk for optimum use. Give the OS plenty of swap space, don't be stingy. That's how you do it. Take away the I/O burden of the CPU and the humble AT chassis can support that kind of load for OA and databases. CAD/CAM and robotics would be a different thing. Oh, and running DOS ala VP/ix and DOSmerge would subtract from the number of users as well. DOS is such a pig that it reminds me of some of our governments: take all and give back very little. :-) :-) :-) :-) :-) -- Jeff Tye ncar!noao!asuvax!hrc!swusrgrp!jeff southwest!/usr/group is the Southwest U.S. chapter of /usr/group
rbradbur@oracle.oracle.com (Robert Bradbury) (07/07/89)
Das _fixix05cle!om <1 p.s: <1<1<<ecece.i.i.1zereereeeew1z1z1'ttt6GFFFix0d:ix0ury? ? ?:35I5I5555p@@@s:@ooo_1FzokR=zok9_R=#tDX9`RPP]]1Fkx EB%Zo; I55k'66LlOXiRLW3k|||`RP3(1FR<fffee*Tk|z*k|z*Q* lO&E ;;X X'Zb1?kkklOe txX/$*c>^*T)L8#*k'''h1?2 +pZ%ff*T4C1`i* XGGQ*bT4CE,MT4CbJpGG;;1/#E,3beTTTeTRLl6VVV(((;u(1;%%%
fr@icdi10.UUCP (Fred Rump from home) (08/09/89)
In article <14760@watdragon.waterloo.edu> hjespersen@trillium.waterloo.edu (Hans Jespersen) writes: ->In article <1989Jun27.074031.11661@specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes: ->Perhaps a better question is "How many 30+ user 386 systems do you ->know that run (period)." -> ->How many CONCURRENT users ( of typical office automation software ) ->can you respectfully support on a '386 PC ? I know this is vauge and ->will vary considerably depending on the configuration but anyone want ->to give it a shot ? While we have several 32 user systems out there based upon 16MB 15MhZ boxes without cache but with Corollary smart cards, we don't have 32 terminals attached as of yet. Users wanted the ability to add as needed without further hardware modifications. Without having all the facts at hand I believe 16 to 20 terminals is the most actually installed. Of these I would suspect that they are used only as needed for relatively short durations. I.E. folks are not sitting there hacking away at their terminals all day. But the convenience of having the terminal at the desk is the key ingredient that makes it all so worth while. Without having done any real benchmarks 8 to 10 people seem to have negligible degradation. That also seems to be the limit of what our users require in the small business marketplace. Most 386 boxes leave here configured for 8 users. There have never been any speed complaints. Fred -- This is my house. My castle will get started right after I finish with news. 26 Warren St. uucp: ...{bpa dsinc uunet}!cdin-1!icdi10!fr Beverly, NJ 08010 domain: fred@cdin-1.uu.net or icdi10!fr@cdin-1.uu.net 609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schiller
leech@Apple.COM (Jonathan Patrick Leech) (08/09/89)
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. -- Jon Leech (leech@apple.com) Apple Integrated Systems __@/
mike@kse1.UUCP (Michael Miller) (08/25/89)
In article <323@icdi10.UUCP> fr@icdi10.UUCP (Fred Rump from home) writes: >In article <14760@watdragon.waterloo.edu> hjespersen@trillium.waterloo.edu (Hans Jespersen) writes: >->In article <1989Jun27.074031.11661@specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes: >->Perhaps a better question is "How many 30+ user 386 systems do you >->know that run (period)." >-> >->How many CONCURRENT users ( of typical office automation software ) >->can you respectfully support on a '386 PC ? I know this is vauge and >->will vary considerably depending on the configuration but anyone want >->to give it a shot ? >While we have several 32 user systems out there based upon 16MB 15MhZ boxes >without cache but with Corollary smart cards, we don't have 32 terminals >attached as of yet. I know of one commercially available (or soon to be) multi processor (386's) backplane available. It has 32 meg (plus) memory available, copious amounts of disk (something like up to 2.1 GB) and many other features. I know it is AT compatible. I have seen it run 16+ users reasonably and reliably using various desktop packages and doing some compilations of source. This was a while ago tho and they may have gotten more performance out of it since then. I don't know what os it runs currently. They did use specially designed hardware to support the multiprocessing part of the architecture. The system has something like 128 serial ports (I doubt concurrently, but for sporadic users). I have seen it run 64 users (up to about 16+ at any one time) do quite a bit of desktop work and printing in about 90 mins. Actually, it has more than 128 serial ports but a conflict in the device driver for those ports only permitted 128 ports for terminal usage. This may have been resolved by now. Just to make sure people know where I am coming from, I used to work for this purposely unmentioned computer vendor. I was part of this; I worked on the part of the project that got these benchmark results. -- ========================================================== Michael Miller Key Systems Engineering Corp. uunet!keysec!mike 4404 Cavalcade Ct. 1-301-731-7310 Burtonsville, MD. 20866
pcg@thor.cs.aber.ac.uk (Piercarlo Grandi) (08/26/89)
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
fmcgee@cuuxb.ATT.COM (~XT6510300~Frank McGee~C23~L25~6326~) (08/30/89)
In article <PCG.89Aug25214204@thor.cs.aber.ac.uk> pcg@thor.cs.aber.ac.uk (Piercarlo Grandi) writes: >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. There are some cases where a single large drive will perform better than two smaller ones. A lot of controllers out there in PC-AT land are not as smart as many of us would like. For instance, the Western Digital 1007-WAH controller has a 16K track buffer on it. If you have one disk, it helps with performance. If you have two disks, performance gets worse because it can't use the track buffer as much as with a single disk (it has to be flushed before it can read/write to the other disk). With this particular controller, one 300 MB is better than two 150's. If you have multiple controllers or SCSI your statement would be very true though. Frank McGee, AT&T Tier 3 Indirect Channel Sales Support attmail!fmcgee -- Frank McGee, AT&T Tier 3 Indirect Channel Sales Support attmail!fmcgee
jr@frog.UUCP (John Richardson) (09/01/89)
In article <120@kse1.UUCP>, mike@kse1.UUCP (Michael Miller) writes: > In article <323@icdi10.UUCP> fr@icdi10.UUCP (Fred Rump from home) writes: > >In article <14760@watdragon.waterloo.edu> hjespersen@trillium.waterloo.edu (Hans Jespersen) writes: > >->In article <1989Jun27.074031.11661@specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes: > >->Perhaps a better question is "How many 30+ user 386 systems do you > >->know that run (period)." > >-> > > I know of one commercially available (or soon to be) multi processor (386's) > backplane available. It has 32 meg (plus) memory available, copious amounts > of disk (something like up to 2.1 GB) and many other features. I know it > is AT compatible. I have seen it run 16+ users reasonably and reliably using > various desktop packages and doing some compilations of source. This was a > while ago tho and they may have gotten more performance out of it since > then. I don't know what os it runs currently. They did use specially > designed hardware to support the multiprocessing part of the architecture. > > The system has something like 128 serial ports (I doubt concurrently, > but for sporadic users). I have seen it run 64 users (up to about 16+ at > any one time) do quite a bit of desktop work and printing in about 90 mins. > Actually, it has more than 128 serial ports but a conflict in the device > driver for those ports only permitted 128 ports for terminal usage. This > may have been resolved by now. > > Just to make sure people know where I am coming from, I used to work for > this purposely unmentioned computer vendor. I was part of this; > I worked on the part of the project that got these benchmark results. > -- > ========================================================== > Michael Miller Key Systems Engineering Corp. > uunet!keysec!mike 4404 Cavalcade Ct. > 1-301-731-7310 Burtonsville, MD. 20866 I'd be ***REAL*** interested in any such machines. I have a multi-processor UNIX OS that I have ported to the '386 AT systems, and I can not use its multi-processor features until one of these machines come out. We are building an OLTP product using 33 MHZ 386 motherboards, and want to upgrade to multi-processor as soon as I can get hardware from someone. JR