Path: utzoo!attcan!uunet!mailrus!ncar!tank!gargoyle!ddsw1!karl
From: karl@ddsw1.MCS.COM (Karl Denninger)
Newsgroups: comp.unix.i386
Subject: Re: commport boards and MNP/etc (was: Error-correcting modems & uucp
Summary: And how do you expect to do that?
Message-ID: <1990Apr11.164509.4045@ddsw1.MCS.COM>
Date: 11 Apr 90 16:45:09 GMT
References: <963@frcs.UUCP> <21466@nuchat.UUCP> <511445@nstar.UUCP> <1990Apr8.154834.1545@ddsw1.MCS.COM> <630@gvlv2.GVL.Unisys.COM>
Reply-To: karl@mcs.MCS.COM (Karl Denninger)
Organization: Macro Computer Solutions, Inc. - Mundelein, IL
Lines: 30

In article <630@gvlv2.GVL.Unisys.COM> kleonard@gvlv1.UUCP (Ken Leonard) writes:
>In article <1990Apr8.154834.1545@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes:
>* 
>* We >can't< run hardware flow control, since we have an Equinox board, which
>* doesn't support both it and modem control on the same port.
>* 
>Which brings up a question we're trying to sort out...
>Which multiport boards (especially for more than eight ports per CPU)
>support modem control _and_ flow control _and_ run with less CPU overhead
>than "native" com1/com2 ports (i.e. on a PClone-386 box)?

One question:

If you're using ISC, or AT&T, or ESIX Unix, there is NO IOCTL to turn on and
off hardware flow control!

That is, there is no way to command the board to enable it, unless the board
vendor has inserted some hack (read: external command) to do so on a
port-by-port or (much worse) board-by-board basis.

Xenix and SCO Unix >do< have IOCTLs to handle this.  

I do like the idea of hardware flow control, but it assumes a few things --
one being that your Operating System knows how to support it.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910]
Macro Computer Solutions, Inc.   "Quality Solutions at a Fair Price"