The "Final" Word on 3b1 HFC

[Floyd Davidson]

In article <1991May18.175656.2858 at fithp> mhw at fithp (Marc Weinstein) writes:
>Well, it is almost time to give up.  Thad's article seemed to sum it up
>quite nicely.  It appears that HFC, with some playing on our part, works
>just fine when sending data out, but is worthless on incoming data.  Here's
>what we saw...
>
>
>Now, to adequately demonstrate that HFC works in one direction, we now
>set one of the port speeds to 9600 baud.  Now, if the system with the
>9600 baud port speed sends data to the one with the 19200 port speed,
>then the port speed on the sending system is limiting the rate of 
>transfer - everything works fine.  If the receiving system is the one
>with the 9600 port speed, then the following happens.  The modems
>continue to talk at the same rate, but the modem at the receiving end
>starts to buffer incoming data, since the data is arriving faster than
>the port can offload it, and eventually the modem detects pending
>overflow.

Maybe it does, maybe not. but...

> So, the modem asserts HFC, which is detected by the sending
>modem, which asserts HFC to the 3b1.  Now, the port at the 3b1 detects

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.
(Actually the receiving modem will not even be asserting HFC in
the example given.)

It seems there is a basic misunderstanding here about how data flow
control works.

I'm sending Marc a more detailed explanation by email rather than
post it.  I would suggest that anyone else who wants further
information on this should bring it up in the comp.dcom.modems
group.

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.