purchasing

[terry]

In article <111 at wynalda.UUCP>, danielw at wynalda.UUCP (Daniel Wynalda) writes:
> 
> I am looking for a new unix system.  I am going to purchase a system
> that supports 32 users at the moment and will be capable of running 64
> to 128 users without serious degradation.

	Quite a trick.  What is 'without serious degradation'?

>                                            Most of the users will be
> running Business Basic functions and a few will be doing C development,
> word processing, or news browsing.

	Word processing is a system-hater.  So is C developement.  I don't
know what the current stats are on UNIX business basic (bbx) from BASIS,
but I suspect I/O overhead to be as much or more than WP.  Heavier than most
programs, if you're talking Open systems accounting, but you probably are
not going to find a better way to do your accounting (Open systems is written
in bbx, which is a sort of Basic IV for real computers).  News browsing,
likewise, is a heavy overhead operation.

>                                     I would prefer a System V Unix
> system, but am open to suggestion.

	The ICON system you are about to mention has a pretty good Berkley
for the 680x0, and also a SysV.  We currently have one in-house.

>                                     Could I please have input, both good
> and bad on anyone running this type of system at the moment.  I would
> like input from regular users, rather than promises from salesmen.  Any
> input is appreciated.
> 
> Also, if anyone is familiar with the ICON 4000 or ALTOS 2000 machines, I
> would appreciate input on how they like the systems.  I would like as
> much help from the net as possible because the expertise lies here.

	Having used both systems, I note good things about both, and bad things
about both.  I'll do the ICON and then the 2000.

ICON:

	ICON is a company located nearby (provo/orem area) to us;  therefore,
despite it's relative newness (Altos is very old anyway), it has a very good
product.  There are a number of drawbacks to the system we have inhouse, and
I am told most of them are corrected in newer hardware.

	DRAWBACKS:

		The ICON system visiting us is a 3 processor (68020's) box
	based on loosley coupled message passing in it's architecture.  The
	controlling processor talks to both a dasdy processor (8 meg cache)
	and an I/O processor (Don't know; several meg in buffers, at least).
	The drawback is that the main processor 'talks' to all it's devices
	through a 4 meg 'window'.  This means with few users, it runs the
	user process in core, but with a lot (32) it can tend to swap more
	than would be necessary if this were larger.  In addition, since the
	disk cache is so large, most of your swapfile (being one of the most
	frequently accessed things on a disk) if not all, is usually in the
	cache.  It seems to me that this could be better used as main memory,
	rather than some place to swap main memory to.

		ICON systems is sort of partnered with Sanyo (I don't know
	the exact relationship)... the system we have has a Sanyo terminal
	(apparently a key-code PC-ANSI type) and the name 'Sanyo' is on the
	front of the box under ICON.  While supposedly the console and
	obviously designed (color-coordinated) to go with the main box, the
	cursor keys are not correctly defined in termcap or terminfo.

		ICON apparently has ported (or had ported) to their SysV
	version of UNIX with all the bugs from the 3B2 tty.c that almost
	everybody but SCO seems intent on keeping in UNIX, and that even
	card manufacturers for SCO like to link back into the SCO kernal
	when you install their multi-port boards.

		Not having talked to Tom (head honcho at BASIS) lately, I
	am unaware as to weather or not BBX runs on this box under either
	SysV or Berklix.

	GOODIES:

		I was unable to crash the Berklix at all.  I haven't really
	tried to crash the SysV.

		ICON is *very* responsive to customer needs/complaints.  I
	have had some needs and no real complaints for them, so far.

		ICON can support an 'AT' internally via a 80x86 board,
	allowing users to run PC programs on their various terminals (hence
	the console, I suppose).

		ICON hauls ASCII.  Literally.  Our comm software didn't
	lose characters at 19200 during a data-compressed transfer, and we
	send and receive DAMN fast large packets.


ALTOS 2000:

	The Altos 2000, unlike other Altos equipment is NOT Xenix; it is
system V.  As such, there are a number of drawbacks and benefits associated
with it.  Benefits are derived mainly by the fact that it is so popular that
Altos support is very good for it.

	DRAWBACKS:

		The tty.c is ported from the 3B2; this means you can crash
	your system with a modem if you are not diligent.  Digilent means you
	follow instructions on recommended configurations accurately.

		The Altos 2000 has 9 pin rather than 25 pin ports, meaning
	you have to have your cables made.

		The cabling information supplied with the user documentation
	is from the 886/2086 operators guide and is not strictly accurate,
	due to the changeover from Xenix to UNIX.  Specifically, you have
	to hold RTS high in order to be able to call out, as some modems
	only hold RTS high when CD is present and SysV tty.c likes RTS all
	the time or it returns an EOF when you read, even if you correctly
	use the partial open hack.  This dates back to when AT&T thought
	that thir modems were all that anybody should ever hook up to a
	system.

		I/O is generally limited to 9600 baud under a small (6) to
	moderate (16) user load.  Like previous Altos equipment, if you do
	I/O too fast, it can lose an interrupt (interrupts from the comm
	controller are apparently not stackable).  Once lost, the driver
	for that port goes off into oblivion.  The only way to get it back
	is to kill all process on that port, disable it, then re-renable it.
	NOTE: This is not as bad as the older SCO systems which, when they
	lost an interrupt, wrote tty data all over /dev/kmem instead of into
	the clist structs and double-panicked the machine.  This is recoverable
	on the 2000; SCO has fixed the problem anyway on their Xenix.

		Not having seen an outrageous user load (64 users) on a 2000,
	I am not in a position to comment (but I will anyway :-) ).  I am
	skeptical of and 386 box claiming 64 users.  We do communications
	software, and I know from personal experience that a DMA controller
	on a 386 still bogs the system when a serious amount of I/O is going
	on.  In addition, the more users, the more I/O, and the more blocky
	I/O would get.  I will have to see a 386 system run 64 users to believe
	it.  I don't want a contived demo either.  I want to see at least 5
	c compiles and 15 WP sessions going at the same time.

		Altos has gone and included the broken wy50 termcap entry
	again.  It seems everybody has at least once.  You'd think that
	people would realize you shouldn't include the \EH in the GH GV and
	G1-G4, etc. if you have GS and GE defined as \EH^B and \EH^C,
	respectively.  Sigh.

	GOODIES:

		I *know* BBX runs on the 2000 ...we did a port to the 2000
	down at BASIS, the guys who wrote Business Basic for UNIX.  That's
	what bbx is.

		The problem with the tty driver has been answered here.  Tie
	CTS high.

		There is a *large* installed user base of 2000's.  Altos HAS
	to fix problems if any occur.

CONCLUSION:

	The ICON is probably better, considering the number of users you plan
to run _unless_ 1) Altos can demonstrate the ability (an installed site who's
willing to talk) to run that many users -or- 2) ICON does not run BBX... you'll
have to ask BASIS on this one.


DISCLAIMER:

	I am in programming and am the tech support manager for Century.  While
it is true we have ditributed thru BASIS (we emulate a Basic IV terminal on
PC's/UNIX/XENIX/VMS, as well as vt100's, wy50's, and assorted Televideo's, etc)
they are the sole manufacturer of BBX.  They wrote it.  I receive no money
(except in a round-about way) from the sales of our software on either ICON
or Altos 2000 systems, so can claim no intrinsic bias.


	It is possible most people are not interested in this type of thing
(this article comparing systems).  If not, flame me and I will cut it out;
it seemed a pity to waste this much typing and thot on a single mail message,
though :-).


| Terry Lambert           UUCP: ...!decvax!utah-cs!century!terry              |
| @ Century Software       or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |