Xenix reliability (Was: Re: Bell Tech 386 SysVr3)

[Karl Denninger]

In article <152 at ispi.UUCP> jbayer at ispi.UUCP (id for use with uunet/usenet) writes:
>In article <1988Jul30.141708.3175 at gpu.utcs.toronto.edu>, woods at gpu.utcs.toronto.edu (Greg Woods) writes:
>> 
>> Anyone who thinks Xenix is reliable has NEVER seen a truely reliable system.
>
>I don't understand what you are referring to.  We have sold, installed, and
>support more Xenix systems than you have.  Over the past year our customers
>have had a grand total of 3 crashes.  All of these crashes were on one computer
>leading us to suspect hardware.  While the kernel may have bugs I have not
>been impacted by them to a large extent.

Well, the bugs you've noted to me (in email) had to do with IPC and the like
(SV shared memory).  I've got a nice application here, written here, that
uses SV shared memory, semaphores and message queues, and it works fine.

It also runs on Unix V.3, without changes.  Simple compile and go.  It beats
the living daylights out of these facilities too -- especially when a
half-dozen people are using it!

No crashes yet..... (we started this one with some trepidation due to Mr.
Woods' earlier warnings; they haven't been justified for us as of yet).

(BTW: Our system is limited in it's uptime by only two things:  The need
      to go to single user mode to back up the root file system, since we
      use cpio, and the utility company's whims.  We haven't bought a UPS
      since we have *never* had a file system corrupted due to a power hit.
      It is not at all unusual to run for several weeks, only to take a hit
      when Edison kills the power.)

>> The Xenix serial driver cannot share interrupt vectors with more than
>> one port.  It will lose data at 1200 baud.
>
>I normally don't tell people that they don't know what they are talking
>about, but you don't.  

Note also that we run Trailblazers on a dumb board; they work fine with no
character loss problems at all!  I won't say that it doesn't severely impact
performance when there are two lines up at 19200 -- it DOES.  But this is
something I expect.  I do not expect lost characters -- and so far I haven't
seen many.

>Regarding the interrupt vectors, you are correct.  However, I would like to
>know if the 386/ix product can share the interrupt vectors.  You don't say.

Not quite:  We have a Digicom/8 in our box; 8 ports, and *ONE* interrupt
vector.  Works quite nicely too....  (what was that about shared interrupts
again?)

The *only* problems I have had with SCO to date are:
	1) awk is compiled in small model '286 code (in fact, MANY of the
	   utilities in SV/386 are).  As a result it can be pushed too hard
	   and will run out of table space -- which causes it to dump core.
	   SCO can fix this by recompiling the utilities in '386 small model.

	2) The uucp (V7-ish) bites.  Corrected in the August 15th upcoming
	   release (HDB included).

	3) The tty driver may have a small problem -- it appears that while
	   CTS works as intended (ie: the remote device can stop output by
	   dropping CTS), RTS does not.  Setting 'rtsflow' on simply stops
	   all activity, regardless of the state of the affected pin(s). 
	   This *might* be a problem with our board; we haven't investigated
	   it yet. 

We have sold Microport (and still do if someone wants it), but we recommend
SCO at present.  This is for one very simple and basic reason -- it works, 
out of the box, without changes, and without hours of hackery..  I've used 
Uport/386, and it was an exercise in frustration trying to get a second 
disk drive installed.  (We won't even discuss SV/AT from Uport; I can't keep 
the obscenities from spilling over the keyboard when I write about it).

SCO allows you to take nearly anything you want, plug it in, and have it
work.  Specifically: tape drives, multiport serial (dumb) I/O boards,
"wierd" disk drives, and other items that either require drivers for anyone
else's UNIX varient, or don't work at all.

I haven't had a "panic" or other system crash since we had a memory board go 
out -- and I can hardly blame *that* on the OS...

--
Karl Denninger (ddsw1!karl) Data: (312) 566-8912, Voice: (312) 566-8910
Macro Computer Solutions, Inc.    "Quality solutions at a fair price"