Bell Tech 386 SysVr3

[Greg Woods]

In article <215 at milhow1.UUCP> how at .UUCP (Mike Howard) writes:
>In article <1988Jul30.141708.3175 at gpu.utcs.toronto.edu>, I write:
>>
>>> The Xenix serial driver cannot share interrupt vectors with more than
>>> one port.
>ok - but why is that a problem?  Seems like the serial driver is busy
>enough that you _wouldn't_ want it to share a vector.

Unfortunately, it does share vectors.  There are only 4 commonly
available interrupts for serial ports in the first place, and often 8
ports share one vector.  Unless the board has hardware to "stack"
interrupts, characters will get lost.  Even AT&T have had this problem
(see the SVR3.0 release notes for the 3B2).

>>> It will lose data at 1200 baud.
>Crap.  I have a Compaq 286 (8 MHz) running SCO Xenix 2.2.1 with a Hostess
>8-port board as COM2.  That board simultaneously drives:

To be specific, it was a 16 MHz Olivetti 386 running SCO Xenix V/286
2.2.1 with an AMI-LAMB 8-port as COM2.  The eight'th port was looped
back into the first port.  XON/XOFF was turned on, and a file was cat'ed
through at various baud rates.  The resulting data loss showed why our
application was behaving so poorly (an RS-232 LAN).  When we repeated
this test in various versions of the Olivetti 286, and in a 6 MHz
IBM-AT, the problem only escalated.  The IBM even lost characters at 300
baud.

>Xenix is not always Xenix and performance depends on who ported it -
>especially the drivers.

I spent a lot of time on the phone with SCO, who wrote and ported the
version I was using.

>-- 
>Mike Howard
>uunet!milhow1!how


-- 
						Greg Woods.

UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods
VOICE: (416) 242-7572 [h]		LOCATION: Toronto, Ontario, Canada