Path: utzoo!utgpu!watmath!uunet!wuarchive!gem.mps.ohio-state.edu!usc!sdsu!polyslo!cindy!csusac!cs255113
From: cs255113@csusac.csus.edu (Dave Jenks)
Newsgroups: unix-pc.general
Subject: Re: ESIX
Summary: beware of advertising...
Keywords: ESIX, SYSV
Message-ID: <1989Nov13.060903.21928@csusac.csus.edu>
Date: 13 Nov 89 06:09:03 GMT
References: <2559B8BB.27170@maccs.dcss.mcmaster.ca>
Sender: ucbvax!ucdavis!csusac!cs255113
Reply-To: cs255113@csusac.UUCP (Dave Jenks)
Distribution: unix-pc
Organization: California State University, Sacramento
Lines: 34

I have ESIX running on an Intel 302 ('386, '387, etc.) in my
office, and have discovered the following:

    While the system _seems_ to run faster during normal operation,
    the package I am porting ran 20-30% slower than on the same machine
    running SCO XENIX.

    The kernel supports over 16MB (we need 24MB for the graphics images
    we are generating), but, while XENIX maxes at 16MB, ESIX has a
    really rough time with its $MB segment sizes; that is, when your
    program hits 8MB, things get noticably (but not painfully) slower.
    When you hit 16MB, especially doing bit-blting in the higher memory,
    the system drags its butt like an old PDP 11/34 running INGRES.  We
    ran proprietary benchmarks with the following results:

	To draw an M.C. Escher work using recursive "fish":

	under 8MB of total memry used:  120 seconds
	8.4MB total:			260 seconds*
	17.4MB total:			1800 seconds (30 minutes!)

    Note:  the second figure represents an increase in resolution;
    therefore, we expected an increase in time.  The last figure
    should not have increased by a very large amount, since all we did
    was increase the total size of the "page", not the image.

    Of course, if you're not interested in gigantic programs, I'd go for
    it.  The support is excellent, though we had to push a little to get
    someone who spoke fluent English.  We described the problem to them,
    and they were extremely interested in correcting the problem.

    ESIX _does_ claim XENIX code-compatibility, which we are likely to
    be attempting very soon.  E-mail me at the above "Sender" address
    if you're interested in our results when something is accomplished.