more on the HFC saga

[Marc Weinstein]

>From article <1991May16.184350.27211 at ingres.Ingres.COM>, by daveb at Ingres.COM (Dave Brower):
> In article <2793 at public.BTR.COM>, thad at 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.
>> ...
> 
> 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.

It would really be a question of rewriting the incoming character offloading
code, to make it apply HFC when *some* condition arises.  That could be
when the interrupt buffer is seen to be getting full.  The problem is that
it assumes that the 3B1 can keep up.  If we were to achieve true 19200
throughput, which for simplicity we'll say is ~2000 Bps, this would imply
that the 3B1 would have to be able to keep up with interrupts being
generated 2000 times/sec, leaving some 500 microseconds to service each
interrupt.  My guess is this poses real problems for the microprocessor.
I don't think it can keep up.

The real solution would have to come in the way of buffered tty's or
a DMA for tty activity.

> I'm assuming by the quoted article that the HFC is
> visible to the kernel, but that it is being ignored.

No - with HFC properly turned on (see other articles) the kernel WILL
stop the flow of data on an outgoing port when the CTS signal is negated.
It's incoming data which is the problem.

-- 
Marc Weinstein
{simon,royko,tellab5}!linac!fithp!mhw		Elmhurst, IL
-or- {internet host}!linac.fnal.gov!fithp!mhw