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
allen@sulaco.UUCP (Allen Gwinn) (08/08/88)
In article <5084@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes: > thirty one days looks like reliable to me. I've got you beat! I have gone 92 days without a crash. -- Allen Gwinn ...sulaco!allen allen@sulaco.UUCP Disclaimer: I speak for myself only (thanks Oleg)
daveh@marob.MASA.COM (Dave Hammond) (08/08/88)
In article <212@sulaco.UUCP> allen@sulaco.UUCP (Allen Gwinn) writes: >In article <5084@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes: > >> thirty one days looks like reliable to me. > >I've got you beat! I have gone 92 days without a crash. Without getting too deep into this debate, I will add that I have SCO 2.1.3 and 2.2.1 running on several 286's (6mhz IBM, 10mhz Everex, 10mhz Compaq...) and none has "crashed" in recent memory, except when at the mercy of the power company. With a UPS installed, the only time a system is down is when the sysop brings it off-line. All systems run Arnet Smart-8 multi-port boards, 60mb tape drives, and at least 8 concurrent users (sysops usually log in on several console multiscreens) on 2 shifts daily. In my opinion, if you are alone in a lab and hacking (you may substitute "researching") a Unix system - uPort is fine. If you have customers who are NOT computer wizards, and you do not want to hear "why is this so slow ?", "what's a core dump?", et.al, and you do not want to be spending your time hand holding... Xenix. Dave Hammond /dsix2!daveh UUCP: {uunet | rutgers | spl1 | ...}!{masa.com | hombre}!< DOMAIN: dsix2!daveh@masa.com \marob!daveh USMAIL: DSI Communications Inc, 333 W. Merrick Road, Valley Stream, NY 11580 ----------------------------------------------------------------------------
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
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