Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!gandrews From: gandrews@netcom.COM (Greg Andrews) Newsgroups: comp.sys.3b1 Subject: Re: Modem-to-modem flow control (was Re: The "Final" Word on 3b1 HFC) Summary: Okay, I'll back up to the previous messages. Message-ID: <1991May20.042242.28817@netcom.COM> Date: 20 May 91 04:22:42 GMT References: <1991May19.030549.3983@ims.alaska.edu> <2825@public.BTR.COM> <1991May19.144854.24339@ims.alaska.edu> Distribution: na Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 97 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@ims.alaska.edu> floyd@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@netcom.COM | `------------------------------------------------------------------------'