Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!mtxinu!rtech!ingres!Ingres.COM!daveb
From: daveb@Ingres.COM (Dave Brower)
Newsgroups: comp.sys.3b1
Subject: Re: more on the HFC saga
Message-ID: <1991May16.184350.27211@ingres.Ingres.COM>
Date: 16 May 91 18:43:50 GMT
References: <1991May13.010730.4743@fithp> <2793@public.BTR.COM>
Reply-To: daveb@Ingres.COM (Dave Brower)
Distribution: na
Organization: Ingres Division, ASK Computer Systems.
Lines: 19

In article <2793@public.BTR.COM>, thad@public.BTR.COM (Thaddeus P. Floryan) writes:
>Recent private conversations with "people who should know" (:-) have elicited
>the info that HFC on *INPUT* is *NOT* implemented in *ANY* kernel that CT has
>produced.  Many (most?) of CT's systems were 68020-based, and the *NEED* for
>HFC at 19200 was non-existent as proved by my own tests on two MightyFrames;
>as an aside, HFC at 38400 on the MightyFrames is also not needed except for
>worst-case zmodem transfers where, in my tests, I encountered only ONE serial
>port overrun in over 200MB file transfers during the tests.  And, again, from
>a "person who should know", examination of the kernel source code verifies
>that INPUT HFC is non-existent; output HFC is compiled-in and works just fine

Is there a chance that replacement tty drivers could make HFC work, or
would it be done somewhere else?  Not that re-writing a tty driver is
easy, but given some of the other things people have done, it may not be
out of the question.  I'm assuming by the quoted article that the HFC is
visible to the kernel, but that it is being ignored.

thanks,
-dB