Modem-to-modem flow control (was Re: The "Final" Word on 3b1 HFC)

[Greg Andrews]

In article <1991May19.144854.24339 at ims.alaska.edu> floyd at ims.alaska.edu (Floyd Davidson) writes:
>
>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...)
>

You're giving a pretty all-encompassing statement there, and it is true,
but ONLY under one condition:  No modem-to-modem error correction is active.

If the modems have negotiated an error correction protocol (such as MNP or
V.42) then the sending modem will indeed receive a flow control signal when
the receiving computer tells the receiving modem to halt (whether via hardware
flow control or software flow control).  Modem error correction protocols
include a mechanism for flow control messages between the modems, and if
the receiving modem's buffers fill up it will signal to the sending modem
that trasmissions should stop.  

>
>  [quoting Thad's message]
>> 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?  
>
>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.)
>

While this last statement is indeed true, it's not the whole truth.
As I mentioned above, the T2500 can and will assert flow control (whether
hardware or software) whenever its transmit buffer is full.  The buffer
can get filled when the receiving modem has said "stop transmitting to me"
through the flow control mechanisms in MNP or V.42.

>
>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.                      ^^^^^^^^^^^^^^^^^^^^
>^^^^^^^^^^^^^^^^^^^^^^^^^

Hello.  I'm here to tell you that it WILL when error correction is active.
It doesn't send HFC signals, to be sure.  But it does send flow control
signals ("messages" is a better term) through the error correction protocol.

>
>  [some references to Thad's message deleted]
>
>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.
>

Again, when error correction is active, you'll get exactly that.  The data
would come across the phone line in a packet, and the receiving modem can't
release that data until the whole packet arrives intact.  As soon as the
modem checks the packet for errors, it releases the data to the computer at
the full speed of the RS232 interface.  19.2 Kbps, in your example.

Thus the computer receives data at an AVERAGE of 2400 bps, but the computer's
ability to handle the data rests on how it can handle data in bursts as well
as over the average.  With error correction active, the modem would feed 
data to the computer in full speed bursts with pauses between each burst.  
The amount of data in each burst will depend on the data flow and which error 
correction protocol is being used.  MNP4 can use up to 256 byte packets, with 
MNP5 compression increasing that up to about 500 bytes.  V.42 can use packets 
up to 4096 bytes in length, with V.42bis boosting that up to 16,000 bytes.  

Of course, the REAL data burst lengths after decompression will vary, and 
probably won't be as large as the numbers I've stated here.  My point is that
the receiving computer will receive bursts of data at full speed, and those
bursts can be fairly large in size.  If the computer can't handle that much
data in one burst, then it will drop data on the floor and your statement will 
be untrue.

>
>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.

-- 
 .------------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {apple,amdahl,claris}!netcom!gandrews    |
 |                 |   Internet: gandrews at netcom.COM                      |
 `------------------------------------------------------------------------'