The "Final" Word on 3b1 HFC

Floyd Davidson floyd at ims.alaska.edu
Mon May 20 00:48:54 AEST 1991


In article <2825 at public.BTR.COM> thad at public.BTR.COM (Thaddeus P. Floryan) writes:
>In article <1991May19.030549.3983 at ims.alaska.edu> floyd at ims.alaska.edu (Floyd Davidson) writes:
>{comments re: HFC on the 3B1 per the extractions:}
>
>>	Maybe it does, maybe not. but...
>>	[...]
>>	HFC doesn't have anything to do with the rate of data transfer
>>	between the modems.  The sending modem is NOT going to detect
>>	anything as a result of the receiving modem asserting HFC.
>>	[...]
>>	I would suggest that anyone else who wants further
>>	information on this should bring it up in the comp.dcom.modems
>>	group.
>
>Let's not mingle two issues here (HFC and modem transfers).

The original article, quotes from which you did not include, was
concerning modem use.  And the point that I was making was that
there is a misunderstaning about data transfers using modems and
its relationship to hardware flow control.  One of the misunderstood
things is that they are not related and are two separate issues.

>Incoming HFC on the 3B1 simply does NOT work no matter whether one is directly
>connected with hardlines or receiving via a modem.  Besides the fact my own
>tests (in 1987 and 1991) indicate it doesn't work, comments from "reliable
>sources" (no pun) indicate the incoming HFC code has NOT been compiled into
>the distributed code (due to #ifdef ...(and (presumably) untested routines)).
>
>Outgoing HFC works just fine on the 3B1, both over hardlines and modems. Thus
>I disagree with the comment above re: "...sending modem is NOT going to detect
>anything..."

The sending modem is NOT going to detect anything related to HFC between
the receiving port and the receiving modem.  If you are hardwired between
ports it will, but the discussion was about modems, not hard links.
(However, it still won't make any difference, see below...)

> because calling from my office at 2400 baud into a T2500 connected
>to my 3B1 (fixed at 9600 baud) works just fine ... the 3B1 does "somehow"
>detect my office computer's HFC signal to STOP to prevent its (the office
>computer's) buffer from overflowing when the 3B1 is sending at 9600 baud but
>the office computer is receiving at 2400 baud.  Magic?  Swinging dead chickens
>over one's head while dancing under a full moon in one's Jockey shorts?  Dunno.

No not magic.  2400 bps and modem buffering.  There is no signal from
your office modem to the 3b1 to slow down.  The modems are transfering
data at 2400 bps, not 9600.  As long as your office computer can handle
2400 bps it is going to work.

  The T2500 asserts HFC to the 3B1 when its transmit buffer is full.
That has nothing to do with the computer or the modem on the other end.
It is totally between the T2500 and the 3b1 and is intended to keep the
T2500 analog side transfering data as fast as it can, which in your
case is restricted to 2400 bps.  It works very well too.  (And does
because the T2500 is capable of buffering data at the max rate that
the 3b1 can send it at.)

If the data rate between the modems was faster than the receiving end
could handle, then the receiving end would drop data, but at 2400 bps
that is unlikely.  So your experience is interesting, but it does
not in any way prove that the sending modem gets any kind of HFC
signal from the receiving modem.  It doesn't.

>The audience in comp.dcom.modems probably doesn't even know (or care) what a
>3B1 and its problems are, so why burden them?

They probably don't even know what a 3B1 is, but they do understand
flow control and modems.  Try 'em.  And be sure to ask how a Tbit
modem sends HFC signals to the distant modem.  Someone from Telebit
will tell you it doesn't.

>The 3B1 is one heckuva nice system (I have many of them), but it's NOT a
>powerhouse by today's standards.  My 3B1 are (subjectively) faster than the

[ 15 lines of chest thumping about the 3b1 removed]

>Point being: the 3B1 doesn't have enough "horsepower" to handle thousands of
>interrupts per second.

That *is* the point.

>
[ about 50 lines 3b1 advertisements removed  (geeze Thad, we know it is
  a nice machine, why do think we own them.  Are you selling yours?) ]
>

Note that handling interrupts and HFC are two different things.  I have
no idea if the 3b1 really is not asserting HFC on incoming data buffer
overflow, it doesn't make much difference.  It can't handle data
at 19.2 kbps because it can't handle interrupts that fast, HFC or no.

The 3b1 can't buffer data that fast, so how is it going to make HFC work?
(Given the current serial port hardware which requires one interrupt
per character.  If someone wants to design a buffered serial port
card then we might worry about "incoming" HFC a little more.)

Even at 2400 bps between modems one could still have a problem if the
modem to 3b1 rate is 19.2 kbps if the modem buffers receive data and
dumps it to the 3b1 at a full 19.2 kbps rate.

Think about it.

Floyd

-- 
Floyd L. Davidson   | Alascom, Inc. pays me, |UA Fairbanks Institute of Marine
floyd at ims.alaska.edu| but not for opinions.  |Science suffers me as a guest.



More information about the Comp.sys.3b1 mailing list