From: dnichols@ceilidh.beartrack.com (Don Nichols (DoN.))
Newsgroups: comp.sys.3b1
Subject: Re: 3b1 internal modem-flow control
Date: 22 Aug 92 16:48:50 GMT
Organization: D and D Data, Vienna Virginia

In article <Tkayr*4p2@crpi.UUCP> joel@crpi.UUCP (Joel C. Justen) writes:
>In article <1992Aug18.025606.648@ceilidh.beartrack.com>, Don Nichols (DoN. writes:
>
>> In article <1992Aug17.123409.4503@rtsg.mot.com> renkel@rtsg.mot.com (Will Renkel) writes:
>> >Quick question...
>> >Is the unix-pc (3b1, 7300) internal modem capable of hardware flow control?
>> >If so, how do you enable it?

>> 
>> 	As far as I know, no modem in that speed range (1200 BPS) is capable
>> of hardware flow control, because it is just sending data bits down the

	[ ... ]

>> 
>> 	At that speed, why do you even *need* it?
>
>If he's doing anything like me, then I have a good idea.  I currently am 
>hooking up a Supra 14.4 v.32bis FAXmodem up to my unix PC and would like 
>to know the answer to the question also.  Apparently, there is some sort
>of modem control, because I'm able to connect via null modem line to my
>Amiga and get 19200 with very little problems (the max baud for the Amiga).

	As you mentioned (in a following part which I deleted), this is
different since you are using the RS232 port.  There, hardware flow control
works unidirectionally.  That is the system can be told to stop sending
characters, but not (successfully) told to request a halt of characters when
its own input buffer is nearly full.  If your conversations with the amiga
are short packets going each way, the overflow state (which frequently
manifests itself at 19200), doesn't get a chance to build up, since the
machine has times with no input to catch up.  Uucp usually has short enough
packets so that it doesn't hit problems, as long as there isn't something
else interrupt intensive going on, such as ethernet, voice power, etc.

	Anyway, at lest the *lines* are there for hardware flow control on
the RS-232 port.  With the built-in modem, there isn't even the mechanism to
tell the other modem to shut up for a while, so the control lines, whether
present or not, can't do anything.  (External modems like the Telebits with
PEP - their Packetized Ensamble Protocol, are sending packets back and forth
between the modems, and can tell each other to wait a bit, so a hardware
flow control line to the modem is useful.)  Probably the same capability is
present in your FAXmodem, at least in certain modes.  The TeleBit is, of
course, useless with hardware flow control when talking one of the
lower-speed protocols like 1200 or 2400bps.  (Perhaps it can buffer the
information somewhat, since it does have a large internal memory, and thus
could potentially honor HFC for a short while, until the internal buffer
filled up, but would have no way to tell the other end to shut up.

	The original poster sent me e-mail indicating that he was
communicating with another system which had a modem hooked up at a higher
interface speed than that at whic he was connecting.  The real problem here
is not overflow at his end, but overflow at the other end, since his system
can keep up with 1200 with no problem.  What is needed there, is for the
other end to enable hardware flow control in both his modem, and his
computer.  The buffer on the other end's modem is filling up, and it is
either 1) not able to signal that status to the computer, 2) able, but it is
not enabled, or 3) able and enabled, but the computer is ignoring the HFC.
If the computer at the far end were set up properly, it would throttle the
computer down with flow control, even if the computer is sending to it at
38400bps, when it is sending to someone at 1200 bps.  I had alread deleted
his e-mail before thinking of this, so I hope that he is reading this.  The
problem is not at his end, just the evidence of the problem is at his end.

	Good Luck
		DoN.

-- 
Donald Nichols (DoN.)     | Voice (Days): (703) 704-2280 (Eves): (703) 938-4564
D&D Data                  |  Email: <dnichols@ceilidh.beartrack.com>
I said it - no one else   |         <nichols@nvl.army.mil>
	--- Black Holes are where God is dividing by zero ---
Newsgroups: comp.sys.3b1