Path: utzoo!mnetor!uunet!husc6!hao!ames!elroy!spl1!ddsw1!igloo!learn
From: learn@igloo.UUCP (william vajk)
Newsgroups: comp.sys.ibm.pc
Subject: Re: XENIX VS Micoport
Message-ID: <391@igloo.UUCP>
Date: 6 Feb 88 03:28:23 GMT
References: <16217@watmath.waterloo.edu> <166@bhjat.UUCP> <366@igloo.UUCP> <434@cimcor.UUCP>
Organization: igloo, Northbrook, IL
Lines: 56
Summary: faster drives solved only one problem, others remain

In article <434@cimcor.UUCP>, mike@cimcor.UUCP (Michael Grenier) writes:
> You mentioned an improvement going from the 65ms drives to the 40ms drives.
> Perhaps the reason for my success is my faster 28ms drives (maxtor 1140).
> I've had this system running since I installed version 2.3 with dosMerge
> for a couple months now without any crash at all. Maybe Microport
> isn't robust for all hardware configurations but it sures works good
> on this one.


Most of the system crashes disappeared with the installation of 2.3. The
ones that remain are the direct result of hung processes when a remote
user terminates the session without logging off. This usually results
in the OS becoming confused, DTR not being reasserted, and any attempt to
respawn getty ends with a completely hung system and a double panic.

From that standpoint, great strides have been made by microport.

The upgrade of drives has relieved the previously undiagnosed problem
of dropping the uucp feed with an input mode failure when the system was
otherwise idle, the error message being identical to the failures reported
when ths system is not idle during incoming uucp.

Unless the system is otherwise idle *during* incoming uucp, there are
sufficient dropped characters to generate alarms terminating the uucp.

Actually, you don't need a long feed to prove this one way or another
for your system. A 75 to 100 K feed will suffice, if you cat a long
file during the feed, either from one of the consoles or by remote.

The problem is greatest if the remote operates at 300 baud as the
continuous screen refresh steals the interrupt necessary for the
incoming uucp to function.

This history was completely valid until a few days ago, when we installed
a telebit trailblazer and started receiving our newsfeed at 9600 baud.

What has changed is that the manifestation is now reversed for reasons
we have yet to discern. Watching an incoming uucp (usenet news), I permitted
a user to log in at 300 baud, and cat a long file. The packets at 9600
come across fast enough, and there are other intelligent interactions
between the corresponding modems. What previously was an uninterrupted
stream of data going out the 300 baud line (while uucp died) is now
a clearly interrupted stream to the 300 baud line, 180 degrees out of
sync with the RD light on the telebit. Karl Denninger's autobaud getty
was installed to accommodate the 9600 baud modem connection.

Our original hunch of problems with interrupt prioritazation seems
to be reproved at every turn. Once this is fixed, the remainder should
fall neatly into place.

Changing the main drive from a 40 meg 40 ms to a 72 meg, 28 ms unit had
no effect on uucp problems. We maintain a separate drive with a single
partition for /usr/spool.


Bill Vajk                                            learn@igloo