home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / 3b1 / 3189 < prev    next >
Encoding:
Internet Message Format  |  1992-08-22  |  4.3 KB

  1. Path: sparky!uunet!beartrk!ceilidh!hijo-2!dnichols
  2. From: dnichols@ceilidh.beartrack.com (Don Nichols (DoN.))
  3. Newsgroups: comp.sys.3b1
  4. Subject: Re: 3b1 internal modem-flow control
  5. Message-ID: <1992Aug22.164850.15846@ceilidh.beartrack.com>
  6. Date: 22 Aug 92 16:48:50 GMT
  7. References: <1992Aug17.123409.4503@rtsg.mot.com> <1992Aug18.025606.648@ceilidh.beartrack.com> <Tkayr*4p2@crpi.UUCP>
  8. Organization: D and D Data, Vienna Virginia
  9. Lines: 71
  10.  
  11. In article <Tkayr*4p2@crpi.UUCP> joel@crpi.UUCP (Joel C. Justen) writes:
  12. >In article <1992Aug18.025606.648@ceilidh.beartrack.com>, Don Nichols (DoN. writes:
  13. >
  14. >> In article <1992Aug17.123409.4503@rtsg.mot.com> renkel@rtsg.mot.com (Will Renkel) writes:
  15. >> >Quick question...
  16. >> >Is the unix-pc (3b1, 7300) internal modem capable of hardware flow control?
  17. >> >If so, how do you enable it?
  18.  
  19. >> 
  20. >>     As far as I know, no modem in that speed range (1200 BPS) is capable
  21. >> of hardware flow control, because it is just sending data bits down the
  22.  
  23.     [ ... ]
  24.  
  25. >> 
  26. >>     At that speed, why do you even *need* it?
  27. >
  28. >If he's doing anything like me, then I have a good idea.  I currently am 
  29. >hooking up a Supra 14.4 v.32bis FAXmodem up to my unix PC and would like 
  30. >to know the answer to the question also.  Apparently, there is some sort
  31. >of modem control, because I'm able to connect via null modem line to my
  32. >Amiga and get 19200 with very little problems (the max baud for the Amiga).
  33.  
  34.     As you mentioned (in a following part which I deleted), this is
  35. different since you are using the RS232 port.  There, hardware flow control
  36. works unidirectionally.  That is the system can be told to stop sending
  37. characters, but not (successfully) told to request a halt of characters when
  38. its own input buffer is nearly full.  If your conversations with the amiga
  39. are short packets going each way, the overflow state (which frequently
  40. manifests itself at 19200), doesn't get a chance to build up, since the
  41. machine has times with no input to catch up.  Uucp usually has short enough
  42. packets so that it doesn't hit problems, as long as there isn't something
  43. else interrupt intensive going on, such as ethernet, voice power, etc.
  44.  
  45.     Anyway, at lest the *lines* are there for hardware flow control on
  46. the RS-232 port.  With the built-in modem, there isn't even the mechanism to
  47. tell the other modem to shut up for a while, so the control lines, whether
  48. present or not, can't do anything.  (External modems like the Telebits with
  49. PEP - their Packetized Ensamble Protocol, are sending packets back and forth
  50. between the modems, and can tell each other to wait a bit, so a hardware
  51. flow control line to the modem is useful.)  Probably the same capability is
  52. present in your FAXmodem, at least in certain modes.  The TeleBit is, of
  53. course, useless with hardware flow control when talking one of the
  54. lower-speed protocols like 1200 or 2400bps.  (Perhaps it can buffer the
  55. information somewhat, since it does have a large internal memory, and thus
  56. could potentially honor HFC for a short while, until the internal buffer
  57. filled up, but would have no way to tell the other end to shut up.
  58.  
  59.     The original poster sent me e-mail indicating that he was
  60. communicating with another system which had a modem hooked up at a higher
  61. interface speed than that at whic he was connecting.  The real problem here
  62. is not overflow at his end, but overflow at the other end, since his system
  63. can keep up with 1200 with no problem.  What is needed there, is for the
  64. other end to enable hardware flow control in both his modem, and his
  65. computer.  The buffer on the other end's modem is filling up, and it is
  66. either 1) not able to signal that status to the computer, 2) able, but it is
  67. not enabled, or 3) able and enabled, but the computer is ignoring the HFC.
  68. If the computer at the far end were set up properly, it would throttle the
  69. computer down with flow control, even if the computer is sending to it at
  70. 38400bps, when it is sending to someone at 1200 bps.  I had alread deleted
  71. his e-mail before thinking of this, so I hope that he is reading this.  The
  72. problem is not at his end, just the evidence of the problem is at his end.
  73.  
  74.     Good Luck
  75.         DoN.
  76.  
  77. -- 
  78. Donald Nichols (DoN.)     | Voice (Days): (703) 704-2280 (Eves): (703) 938-4564
  79. D&D Data                  |  Email: <dnichols@ceilidh.beartrack.com>
  80. I said it - no one else   |         <nichols@nvl.army.mil>
  81.     --- Black Holes are where God is dividing by zero ---
  82.