lpz%ocu.DECnet@ORNL-STC10.ARPA ("OCU::LPZ") (07/16/87)
Hi:
We heard all of the complaints about Allin1 performance, but
it looked light-years ahead of any other office automation
software, so we bought it. We use the following account limits:
Maxjobs: 0 Fillm: 255 Bytlm: 36000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 50 JTquota: 1024
Prclm: 6 DIOlm: 18 WSdef: 1024
Prio: 4 ASTlm: 80 WSquo: 2048
Queprio: 0 TQElm: 50 WSextent: 3072
CPU: (none) Enqlm: 200 Pgflquo: 20000
We are running it on a pair of 8600s. Right now we have some bad
memory and have 72 meg on one machine and 52 in the other. I will
probably raise the WsExtent when we get the memory back, but not
because of Allin1. It seems quite happy with 3072 pages. Right
now we have 50 users and 50% Null time. This seems to imply that
we could support at least 80 concurrent Allin1 users, given enough
memory. I really don't know. Now, when other people use SAS or
ISSCO or compile large programs, the CPU gets totally loaded down.
We also get real slow when the cluster loses a node and 100 people
are in Allin1 and others are doing SAS, etc.
You need lots of memory to run Allin1, and that makes the uVAX a
poor choice, unless you only need to support ~10 concurrent users
(I wouldn't recommend more, but I have never used Allin1 on a
uVAX, so it might work anyway). A better idea might be PC Allin1
for the users and use the uVAX as a file server. This assumes
that you have PCs. Of course, you can get IBM compatibles for
around 2k each, so this is also cost effective. Just realize that
you will need big disks on the uVAX.
I have found that ALL of the complaints about Allin1 speed
come from one of two sources:
People who listened to the original DEC Allin1 performance
estimates and now expect it to work with small memory machines;
And those who have slow terminal multiplexers (e.g. DCA, like we
do, on some of our machines) and don't like waiting for screen
repaints. There is some help here, since you can customize
the menus, but it will still be slow. But that isn't Allin1's
fault. It was designed for use with optimum hardware (large
memory, fast terminal support (e.g. terminal servers, DMF32),
etc., and if you try to get around that, you lose. Most of
the competing products use disks for everything, and you lose
on big systems, because you are limited by disk speed. Memory
is both cheaper and faster than disks, after all.
Lawrence
~
-----------------------------------------------------------------------------
ARPA: LPZ@ORNL-STC10.ARPA
MFE: MACINTYRE@ORN
BITNET: LPZ@ORNLSTC
Bell-South: 615.576.0824
US-Snail: Lawrence MacIntyre
Martin Marietta Energy Systems
Bldg 9201-5 MS 8
P O Box Y
------
------Peck@RADC-MULTICS.ARPA (Rodney) (07/21/87)
41