Path: utzoo!utgpu!water!watmath!clyde!att-cb!ihnp4!gargoyle!ddsw1!igloo!learn
From: learn@igloo.UUCP (william vajk)
Newsgroups: comp.sys.ibm.pc
Subject: Re: XENIX VS Micoport
Summary: my problem to live with ? my problem to solve ? what *have* I bought ?
Keywords: Microport, XENIX, speed, profiler, sar
Message-ID: <407@igloo.UUCP>
Date: 18 Feb 88 22:53:50 GMT
References: <16217@watmath.waterloo.edu> <166@bhjat.UUCP> <366@igloo.UUCP> <242@oracle.UUCP>
Distribution: comp.sys.ibm.pc
Organization: igloo, Northbrook, IL
Lines: 126

In article <242@oracle.UUCP>, rbradbur@oracle.UUCP (Robert Bradbury) writes:
> Over the last month I've seen alot of bad press about the speed of
> Microport UNIX.  It started with the Unique article which in my
> opinion gave an excessively negative imaage of Microport UNIX and
> has continued here. 

I don't know how to break the news to you, but this started well before any
_Unique_ article. Looking at the referenced articles list, I note that two
of them in this ongoing discussion originated from igloo. If you want an
image which reflects the true state of microport, I invite you here, to
Northbrook Illinois, to be sysadm for igloo for a week. I am discussing the
'286 product here.


> The basic issue seems to revolve around the speed
> of the two systems as related to disk I/O and serial port I/O.
> Unfortunately people seem to be describing symptoms and complaining
> instead of actually doing some hard research into the nature of
> the problems.

I am the consumer, the end user of the product. Yes, I can complain in
terms of sympotms all I want. I paid for that right. I have done as much
research as is possible for an end user to do (we are not a development
lab here....how many end users are ?) and relayed all available information
to microport. It is the OEM's job to do the hard basic research. Are you
suggesting that we, the users, fix the product for them ? Why, then, would
we need an OEM at all ?

 
> RE: hard disk speed.  Has anyone done the research to determine the
> proper interleave factor for the hard disks?  Has anyone determined the
> interaction between the software interleave (specified during when
> making UNIX file systems) and hardware interleave handled by the
> controller?  Exactly what are the I/O transfer rates you can
> expect under UNIX?

The transfer rates affect the amount of time that interrupts remain
(get this) disabled. I have already noted that with a slow HD, we lost
some uucp connections during extended feeds. This problem went away
when the drive for /usr/spool was upgraded to a fast drive. When the
slow drive captured the interrupt, and the host computer continued to
send, igloo was unable to return a checksum, as the interrupt was 
occupied with the HD, sometimes long enough to have the host time out
and drop the feed. 

> DIGIBOARD COM/8I with another processor (80186) and 8K I/O buffers
> to handle the I/O.

a hardware solution to a software problem ? Gack ! What next ?

> I'm not saying that XENIX is not faster than Microport, after all SCO/
> Microsoft has had 2-3 more years to refine the serial I/O port driver
> and hard disk interleave factors.  The fact that most XENIX development
> was done of VERY SLOW machines gave the developers an incentive to
> improve those features.  Now people have so much CPU power available
> to them that they rarely put themselves in an environment which degrades
> peformance sufficiently to provide an incentive to improve things.

Interesting you should bring up this point. Microport did promise a
*working* product. That means, it is supposed to do unixish things, like
uucp, and it does not perform these functions in an acceptable manner, by
*anyone's* yardstick.

Slow machine vs fast machine for development has no bearing. Microport was
developed on a fast machine, for fast machines, and does not function as
it is supposed to. CPU power ? We ran microport on a 20 mhz '386 machine
loaned to us for a weekend. Yep, stuff zipped along quite nicely, but
essentially nothing changed when it came to getting our newsfeed. It still
failed miserably. There was essentially no difference during uucp between
the 8 mhz '286 machine we normally run, and the '386 20 mhz system. The
poll still failed simply by having either the console, or one user at 2400
baud cat a large file. Fails even faster if the user catting a large file
is at 300 baud.
 
> One of the advantages of Microport over Xenix is that it provides tools
> to analyze the performance of the machine (SAR and the system profiler).
> SAR works.  A sequence like the following:
> 	/usr/lib/sa/sa1
> 	 - execute command(s)
> 	/usr/lib/sa/sa1
> 	sar -y			- give tty I/O statistics
> 	sar -b			- give disk I/O statistics
> 
> These would give us (and Microport) an idea of how heavily the system
> is being used and what the bottlenecks might be.

I believe microport has a lab capable of doing this. I have neither the
time nor the patience. I offered microport officials root privledges
on igloo, and a uucp connection, if they wanted to come play with this
box.
 
> I would be interested in some HARD facts about how many terminals
> you can run at what speeds with and without console I/O, hard disk
> interleave factors, interrupt overhead, I/O bandwidth, etc. for
> machines running Microport UNIX and XENIX.  Then we could give
> the O.S. and the machines a "FAIR" comparison.

During 2400 baud (and slower) uucp, you can run no terminals, no
remote logins, and no console, else you lose the feed because of the
lost character problem, which then results in checksum problems....

With Karl Deninger's autobaud getty in place, and with a 9600 poll,
the losses of incoming uucp become short enough that we do not lose the 
feed. The transfer time is greatly extended however, and characters
are lost with a user attempting to type in into mail (as in elm running
vi.) Also, a user attempting to cat a file at 300/1200/2400 gets a
jumpy interrupted stream. I consider the jumpy stream acceptable, though
it does look quite strange.

I am not interested in comparisons. I am interested in a *working* system.
I wouldn't mind losing some speed, if it worked. I can counter that with
faster hardware. I don't consider lost characters to be acceptable. I 
don't consider feeds lost because of a malfunctioning OS to be acceptable.
 
> Should we develop a set of programs which can measure these things?
> I'm willing to provide the database maintenance for the results.

I have full system accounting running at igloo presently, the problems
predated the installation of accounting. Send me mail. If you're really
interested in solving microport's problems, I'll gladly set up an account 
for you on igloo. I am interested in having a working product. I don't know
about devoting scads of additional time to solve the OEM's problems for them,
but I'll continue to contribute what I consider 'reasonable'.


Bill Vajk                                                  learn@igloo