[comp.unix.i386] How many users _really_ ?

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;
I55k'66LlOXiRLW3k|||`RP3(1FR<fffee*Tk|z*k|z*Q*
lO&E   ;;X X'Zb1?kkklOe txX/$*c>^*T)L8#*k'''h1?2

+pZ%ff*T4C1`i*
XGGQ*bT4CE,MT4CbJpGG;;1/#E,3beTTTeTRLl6VVV(((;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