rho@maccs.dcss.mcmaster.ca (Raymond Ho) (11/10/89)
Hi everyone, I'm plan to get a set of Unix Sys V variant for my 386 computer. However, there're so many of them out there and I hope you guys/gals and help. I've heard of the one called "ESIX". Its price interests me very much. From the ads, $895 US includes: OS System V 3.2 (they said it is an enhanced version of AT&T Sys V 3.2) Development Tools Xwindow 11.?? ( forgot what exactly how they said it ) TCP/IP multi-user license (up to 32 users) also some reports claim that ESIX is the fastest Unix Sys V available for pcs. Do you know anything about this ESIX? They said it is compatible at binary level with Xenix and Unix, is it true? Thanx! Raymond Ho
cs255113@csusac.csus.edu (Dave Jenks) (11/13/89)
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.