Xref: utzoo comp.unix.xenix:2900 comp.unix.microport:1184
Path: utzoo!utgpu!attcan!uunet!milhow1!how
From: how@milhow1.UUCP (Mike Howard)
Newsgroups: comp.unix.xenix,comp.unix.microport
Subject: Re: Bell Tech 386 SysVr3
Summary: the Xenix serial driver works ok
Message-ID: <215@milhow1.UUCP>
Date: 4 Aug 88 14:16:12 GMT
References: <25145@ucbvax.BERKELEY.EDU> <465@sp7040.UUCP> <11643@steinmetz.ge.com> <1988Jul30.141708.3175@gpu.utcs.toronto.edu> <86@jetson.UUCP>
Reply-To: how@.UUCP (Mike Howard)
Organization: Miller/Howard Investments, Malden-on-Hudson, NY
Lines: 32

In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes:
>
>> 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.
>> 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:
 2 HP LaserJets - at 9600 baud
 1 TrailBlazer -  at a fixed interface speed at 9600 baud
 2 hard wired lines - at 9600 baud
 1 Data Device - at 9600 baud
 1 seldom used 1200 baud modem - at (coincidentally) 1200 baud.

All have run simultaneously w/o any character loss.  The flow control
ranges over hardware (the TrailBlazer), Xon/Xoff (the printers and cu
communications over dedicated lines), and `random protocol' (as in uucp)).
Response time is `unacceptable' while driving both printers and a tad
slow when doing a large uucp file transfer (5 Meg per night), but everything
works fine.

In defense of your indefensible statement: I tried Compaq's Xenix (now dead)
initially, and it could barely do 1200 baud w/o loosing Characters?  Is
that what you are talking about?

Xenix is not always Xenix and performance depends on who ported it -
especially the drivers.
-- 
Mike Howard
uunet!milhow1!how