[comp.unix.microport] Xenix reliability

karl@ddsw1.UUCP (Karl Denninger) (08/05/88)

In article <152@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes:
>In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu>, woods@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"

cck@deneb.ucdavis.edu (Earl H. Kinmonth) (08/06/88)

>>>Anyone who thinks Xenix is reliable has NEVER seen a truely reliable system.

I have run SCO Xenix 86 on an ATT 6300 and now run SCO Xenix 286 on an
ATT 6310. In three years I've had only one crash that required a file
system rebuild, and that came with a catastrophic failure of a memory
expansion board. I run 9600 baud file transfers on a leased line in
concert with 1200 baud transfers through a modem plus cpu intensive
tasks (nroff) without a problem. Moreover, the ATT 6310 is NOT on their
list of tested machines.

Some months ago I asked for comparisons of Microport vs Xenix through
the net. The testimonials for Microport tended to have a one or more
lines of the variety, "It's been really great once I got ..., ..., ...
to work." In my case, Xenix has worked straight out of the box, and
when they say they will call back on a problem, they do.

My impression is that you pay something of a premium for SCO and in
return you get premium service. Depending on how you value your time,
it might make sense to go with lower priced alternatives, and then
again, it may not.

I was amazed at how much you could get out of an 8086 box like the
6300. Except for graphics, I had pie-in-the-sky OS 2 capabilities,
three years ago on my 6300 with Xenix 86.

E H. Kinmonth Hist. Dept.  Univ. of Ca., Davis Davis, Ca. 95616
916-752-1636/0776

Internet:  ehkinmonth@ucdavis.edu
           cck@deneb.ucdavis.edu
BITNET:    ehkinmonth@ucdavis
UUCP:      {ucbvax, lll-crg}!ucdavis!ehkinmonth
           {ucbvax, lll-crg}!ucdavis!deneb!cck

jfh@rpp386.UUCP (John F. Haugh II) (08/07/88)

In article <1498@ddsw1.UUCP> karl@ddsw1.UUCP (Karl Denninger) writes:
>In article <152@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes:
>>In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes:
>>> 
>>> Anyone who thinks Xenix is reliable has NEVER seen a truely reliable system.

output of `stat' from crash on rpp386:

	sysname: XENIX
	nodename: rpp386
	release: 2.2.1
	version: SysV
	machine: i80386
	time of crash: Sat Aug  6 17:38:50 1988
	age of system: 31 days, 5 hrs., 27 mins.

thirty one days looks like reliable to me.
-- 
John F. Haugh II                 +--------- Cute Chocolate Quote ---------
HASA, "S" Division               | "USENET should not be confused with
UUCP:   killer!rpp386!jfh        |  something that matters, like CHOCOLATE"
DOMAIN: jfh@rpp386.uucp          |         -- apologizes to Dennis O'Connor

woods@gpu.utcs.toronto.edu (Greg Woods) (08/09/88)

In article <5084@rpp386.UUCP> jfh@rpp386.UUCP (The Beach Bum) writes:
>In article <1498@ddsw1.UUCP> karl@ddsw1.UUCP (Karl Denninger) writes:
>>In article <152@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes:
>>>In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes:
>>>> 
>>>> Anyone who thinks Xenix is reliable has NEVER seen a truely reliable system.
>
>output of `stat' from crash on rpp386:
>
>	sysname: XENIX
>	nodename: rpp386
>	release: 2.2.1
>	version: SysV
>	machine: i80386
>	time of crash: Sat Aug  6 17:38:50 1988
>	age of system: 31 days, 5 hrs., 27 mins.
>
>thirty one days looks like reliable to me.

Not to me.  Besides, how is that system used?  I had Xenix 2.2.1 (286)
stay up for 60 days, but that didn't impress me either.  That system
only did uucp, jove, and cc, etc.  It didn't do a lot of database stuff,
it didn't use IPC intensly, it didn't do high-speed communications.  The
only times I crashed it was with stupid stuff, like raw nroff output to
the console, a hard disk error during swap, and doing something weird
with IPC stuff.
-- 
						Greg Woods.

UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods
VOICE: (416) 242-7572 [h]		LOCATION: Toronto, Ontario, Canada

vandys@hpisoa1.HP.COM (Andrew Valencia) (08/10/88)

/ hpisoa1:comp.unix.microport / woods@gpu.utcs.toronto.edu (Greg Woods) /  5:17 pm  Aug  8, 1988 /
>...
>The
>only times I crashed it was with stupid stuff, like raw nroff output to
>the console, a hard disk error during swap, and doing something weird
>with IPC stuff.

	Could you provide code which crashes it through IPC?  Or a file
I could cat (containing raw nroff output, perhaps) which would crash it?
If you can give us hard data, we can use it to minimize our risk.  I've
run extensively with IPC and had no problem--but there's lots of ways to
use it, so I'm interested in which one breaks it.

				Andy

jfh@rpp386.UUCP (John F. Haugh II) (08/10/88)

In article <1988Aug8.201739.4868@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes:
>In article <5084@rpp386.UUCP> jfh@rpp386.UUCP (The Beach Bum) writes:
>>	age of system: 31 days, 5 hrs., 27 mins.
>>
>>thirty one days looks like reliable to me.
>
>Not to me.  Besides, how is that system used?

if a system is running applications like crash, fuser, and w, which
sco doesn't even include, AND which run around poking in kernel memory,
do you really have to ask HOW it is being used?  lots of cc, compress,
uucp, news, etc.

happy now?
-- 
John F. Haugh II                 +--------- Cute Chocolate Quote ---------
HASA, "S" Division               | "USENET should not be confused with
UUCP:   killer!rpp386!jfh        |  something that matters, like CHOCOLATE"
DOMAIN: jfh@rpp386.uucp          |         -- apologizes to Dennis O'Connor

peter@ficc.UUCP (Peter da Silva) (08/15/88)

In article ... woods@gpu.utcs.toronto.edu (Greg Woods) writes about how
HP systems are more reliable than UNIX:

Some guy at rpp386 said:
> >thirty one days looks like reliable to me.

> Not to me.  Besides, how is that system used?  ...
> It didn't do a lot of database stuff,
> it didn't use IPC intensly, it didn't do high-speed communications...

Well, I dare say that the HP systems that you're comparing UNIX to are
doing a heavy-duty job mix of accounting and word-processing software:
the sorts of things that you're denigrating rpp386 for.
-- 
Peter da Silva, Ferranti International Controls Corporation, sugar!ficc!peter.
"You made a TIME MACHINE out of a VOLKSWAGEN BEETLE?"
"Well, I couldn't afford another deLorean."
"But how do you ever get it up to 88 miles per hour????"

woods@gpu.utcs.toronto.edu (Greg Woods) (08/16/88)

In article <1257@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes:
>In article ... woods@gpu.utcs.toronto.edu (Greg Woods) writes about how
>HP systems are more reliable than UNIX:

I'm not sure how these things happen....

I've never used an HP system in my life!  I don't even like their
calculators! :-) (The workstation I saw recently turned my crank though)

I think the article in question my have mentioned the SUN I'm writing
this on?  It now says:
% uptime
  1:21am  up 61 days, 17:38,  3 users,  load average: 3.05, 2.25, 1.29
% uname -a
gpu.utcs gpu.utcs 4.2BSD vm sun

Too bad gpu generates unbearably long article id's.  Otherwise I might
have traced this one down.

I know it takes time, money, and space, but let's not delete too many
lines next time!  This takes the same kind of resources too!

Don't delete artilce id's either.
-- 
						Greg Woods.

UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods
VOICE: (416) 242-7572 [h]		LOCATION: Toronto, Ontario, Canada