home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!beartrk!ceilidh!hijo-2!dnichols
- From: dnichols@ceilidh.beartrack.com (Don Nichols (DoN.))
- Newsgroups: comp.sys.3b1
- Subject: Re: 3b1 internal modem-flow control
- Message-ID: <1992Aug22.164850.15846@ceilidh.beartrack.com>
- Date: 22 Aug 92 16:48:50 GMT
- References: <1992Aug17.123409.4503@rtsg.mot.com> <1992Aug18.025606.648@ceilidh.beartrack.com> <Tkayr*4p2@crpi.UUCP>
- Organization: D and D Data, Vienna Virginia
- Lines: 71
-
- 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 ---
-