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

[Greg Andrews]

Hi Again Floyd.  In the message I quoted, you stated that the modems don't
pass HFC signals to each other.  When I said no, they do pass flow control
to each other, it's just not *hardware* flow control, you said yes, that's
what I said:  No *hardware* flow control signals are sent.  

[that's a heavily paraphrased rendition of your article]

The reason I posted isn't so much the statements you made in that particular
article, but rather the thread of the entire conversation.  The statements
you made in your last posting, while technically true, I consider to be false
in the context of your other postings.  Here are the statements from the
previous article which convinced me that you were talking about ALL forms of
flow control rather than just hardware:

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

This is a blanket statement covering all types of flow control that might
occur between the two modems.  Or at least, that's the way I read it.

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

And this was what I was responding to when I posted the description of
how error correction provides flow control between the modems.  As I said
explicitly in my article, flow control on the transmitting end can be
directly related to the flow control occuring at the receiving end.

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

Again, given the context, I took the use of "HFC" to be a term relating to
flow control in the general sense, not to hardware flow control specifically.
The phrase "any kind of HFC signal" tends to make me think you're saying "any
kind of flow control signal".  Since it's obvious that the modems don't 
exchange RTS and CTS signal leads through the telephone line, I figured you wer
e saying that no flow control existed between the two modems.  Thus my posting.

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

Yes, I see that I mis-read this part of your message and thought you
were saying it could NOT happen.  Sorry about that.


Floyd, I hope you don't take this posting as just me trying to argue
with you.  I really did think that you were saying there was NEVER any
type of flow control between modems, and I wanted to illustrate why.


On a related issue, you asked Thad what good would flow control do if the 
3b1 isn't able to handle interrupts at 19200 bps.  On the surface, that would 
be completely true.  If the computer can't grab each byte as it comes in, 
trying to assert flow control won't help.  But there's an underlying question 
here:  Exactly WHEN does the 3b1 fail to handle interrupts at 19200?  Is it 
really all the time, like we've been assuming, or is it only during **disk 
writes** that data is dropped?

It was a common problem among IBM PCs (where I learned computing) that the
system could handle high speed data up to the point of a disk write, then
the disk subsystem would keep interrupt hadling off long enough to drop
data at the serial port.  Solution?  The comm program asserts flow control
before it performs a disk write, then de-asserts it afterward.

That type of solution may not be useful for a multuser, multitasking OS,
but it may be the same as what's happening in the 3b1.  If so, there might
be a solution...

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