[comp.unix.xenix] ESIX vs. SCO Xenix

jca@pnet01.cts.com (John C. Archambeau) (03/14/90)

One thing that I have noticed is that there is an NFS product available for
ESIX, but not SCO Xenix.  Judging from what I have read, ESIX is really a Unix
system, not Xenix, and it is no where near as pricy as SCO Unix.
 
Hell, it's even less than SCO Xenix.  The availability of NFS along with
the price is enough to make me look at SCO and sigh in disbelief.  What is SCO
trying to pull here?  Their Unix product is far from solid and they are
abandoning their best selling product.  

Well, SCO, I don't have to tell you what you can do...I'm going to invest in
ESIX, not your Xenix or Unix.  I once had faith in you, but no more.  Maybe
SCO will see the light, but I doubt it.
 
     // JCA

 /*
 **--------------------------------------------------------------------------*
 ** Flames  : /dev/null                     | My opinions are exactly that,
 ** ARPANET : crash!pnet01!jca@nosc.mil     | mine.  Bill Gates couldn't buy
 ** INTERNET: jca@pnet01.cts.com            | it, but he could rent it.  :)
 ** UUCP    : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
 **--------------------------------------------------------------------------*
 */

brad@bradf.UUCP (Bradley W. Fisher) (03/15/90)

There is one aspect of the *NIX wars that I haven't seen discussed
yet ... one that I consider to be of the utmost importance ...
how long does it take to back/restore from tape? So far comparing 
SCO, Altos, NCR, and Interacive , SCO wins hands down! Typically, 
80 megabytes will stream to tape in about 40 minutes under SCO with
a standard Wangtek 5099EN tape drive and PC-36 controller. The same 
amount of data and tape system takes about 3 hours under Interactive.
Altos and NCR are slightly faster than 386ix, but *nobody* beats SCO
in this respect from what I've seen. Why is this?

Being in the service business, I don't usually have a few hours to stand
around waiting for a tape to finish so I can finish putting Humptey Dumptey
back together again after a crash. Also, only my SCO customers aren't 
complaining that it takes *so* long to back up that they can't find 
time to do it.

Now , I haven't seen ESIX yet, but I have seen Everex labeled tape systems
that are really Wangtek (does Everex really make anything of their own?)
and I'm wondering if their port of UNIX (and the tape driver code) is as 
slow in the backup department. Perhaps someone can shed some light (figures?)
on this?

-- 
I'm just a wanna be UNIX guru (IJWBUG)               | Micro Maintenance, Inc.
						     | 2465 W. 12th St. #6
	-== Brad Fisher ==- 		             | Tempe, Arizona  85281
...!asuvax!mcdphx!hrc!microm!bradf!brad		     | 602/894-5526

jca@pnet01.cts.com (John C. Archambeau) (03/18/90)

brad@bradf.UUCP (Bradley W. Fisher) writes:
>Now , I haven't seen ESIX yet, but I have seen Everex labeled tape systems
>that are really Wangtek (does Everex really make anything of their own?)
>and I'm wondering if their port of UNIX (and the tape driver code) is as 
>slow in the backup department. Perhaps someone can shed some light (figures?)
>on this?

If I hang a tape drive off my *nix system, it will be an Archive, not an
Everex.  What makes ESIX more attractive to me is the availability of NFS and
yellow pages NOW, now in blah blah date which SCO promises.  I'm looking at
SCO with more scrutiny than Stallman with GNU.  Alright SCO, where's the
damned NFS for Unix?
 
     // JCA

 /*
 **--------------------------------------------------------------------------*
 ** Flames  : /dev/null                     | My opinions are exactly that,
 ** ARPANET : crash!pnet01!jca@nosc.mil     | mine.  Bill Gates couldn't buy
 ** INTERNET: jca@pnet01.cts.com            | it, but he could rent it.  :)
 ** UUCP    : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
 **--------------------------------------------------------------------------*
 */

davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (03/18/90)

In article <228@bradf.UUCP> brad@bradf.UUCP (Bradley W. Fisher) writes:
| 
| There is one aspect of the *NIX wars that I haven't seen discussed
| yet ... one that I consider to be of the utmost importance ...
| how long does it take to back/restore from tape? So far comparing 
| SCO, Altos, NCR, and Interacive , SCO wins hands down! Typically, 
| 80 megabytes will stream to tape in about 40 minutes under SCO with
| a standard Wangtek 5099EN tape drive and PC-36 controller. 

  I see about 4MB/min overall throughput for backup with SCO. My
definition of overall is from the time my butt hits the chair until I
walk away, so the actual data transfer rate is a good bit better.
However, I do note that on the few occasions when I've had to restore a
backup, the speed is not very good.

  I use dump for most backups, occasionally cpio running through bundle
to improve the performance.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc
"Getting old is bad, but it beats the hell out of the alternative" -anon

pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) (03/26/90)

In article <228@bradf.UUCP> brad@bradf.UUCP (Bradley W. Fisher) writes:

   There is one aspect of the *NIX wars that I haven't seen discussed
   yet ... one that I consider to be of the utmost importance ...
   how long does it take to back/restore from tape? So far comparing 
   SCO, Altos, NCR, and Interacive , SCO wins hands down! Typically, 
   80 megabytes will stream to tape in about 40 minutes under SCO with
   a standard Wangtek 5099EN tape drive and PC-36 controller. The same 
   amount of data and tape system takes about 3 hours under Interactive.
   Altos and NCR are slightly faster than 386ix, but *nobody* beats SCO
   in this respect from what I've seen. Why is this?

The reason is that you are not using any of them properly, and SCO uses a dirty
and potentially dangerous trick. In order to make the tape stream, you
have to overlap disc reads with tape writes (or viceversa). When the
tape streams, it will take less than 20 Minutes to dump 80 megs, not 40
as you are getting.

To overlap disc and tape IO you need buffering and two processes or
more. Try using my own 'team', posted to alt.sources, or 'ddd', posted
to comp.sources.misc, as tape writing filters. Also, try using GNU tar
or pax or afio instead of dump; they are more portable and often faster,
even if admittedly dump/restor is faster on restore...

The trick that SCO uses is to make the tape driver grab a tape buffer
from the filesystem buffer cache, and then write this asynchronously to
the tape device. This sort of works, but does not provide sufficient
overlap, and completely alters the semantics of raw device writes.

The bottom line is that with the right tools you get 4-5 megs per minute
on any UNIX system that has enough filesystem read bandwidth and a QIC tape.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk