gandrews@netcom.COM (Greg Andrews) (05/20/91)
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. >(However, it still won't make any difference, see below...) > You're giving a pretty all-encompassing statement there, and it is true, but ONLY under one condition: No modem-to-modem error correction is active. If the modems have negotiated an error correction protocol (such as MNP or V.42) then the sending modem will indeed receive a flow control signal when the receiving computer tells the receiving modem to halt (whether via hardware flow control or software flow control). Modem error correction protocols include a mechanism for flow control messages between the modems, and if the receiving modem's buffers fill up it will signal to the sending modem that trasmissions should stop. > > [quoting Thad's message] >> because calling from my office at 2400 baud into a T2500 connected >>to my 3B1 (fixed at 9600 baud) works just fine ... the 3B1 does "somehow" >>detect my office computer's HFC signal to STOP to prevent its (the office >>computer's) buffer from overflowing when the 3B1 is sending at 9600 baud but >>the office computer is receiving at 2400 baud. Magic? > >No not magic. 2400 bps and modem buffering. There is no signal from >your office modem to the 3b1 to slow down. The modems are transfering >data at 2400 bps, not 9600. As long as your office computer can handle >2400 bps it is going to work. > > 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.) > While this last statement is indeed true, it's not the whole truth. As I mentioned above, the T2500 can and will assert flow control (whether hardware or software) whenever its transmit buffer is full. The buffer can get filled when the receiving modem has said "stop transmitting to me" through the flow control mechanisms in MNP or V.42. > >They probably don't even know what a 3B1 is, but they do understand >flow control and modems. Try 'em. And be sure to ask how a Tbit >modem sends HFC signals to the distant modem. Someone from Telebit >will tell you it doesn't. ^^^^^^^^^^^^^^^^^^^^ >^^^^^^^^^^^^^^^^^^^^^^^^^ Hello. I'm here to tell you that it WILL when error correction is active. It doesn't send HFC signals, to be sure. But it does send flow control signals ("messages" is a better term) through the error correction protocol. > > [some references to Thad's message deleted] > >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. > Again, when error correction is active, you'll get exactly that. The data would come across the phone line in a packet, and the receiving modem can't release that data until the whole packet arrives intact. As soon as the modem checks the packet for errors, it releases the data to the computer at the full speed of the RS232 interface. 19.2 Kbps, in your example. Thus the computer receives data at an AVERAGE of 2400 bps, but the computer's ability to handle the data rests on how it can handle data in bursts as well as over the average. With error correction active, the modem would feed data to the computer in full speed bursts with pauses between each burst. The amount of data in each burst will depend on the data flow and which error correction protocol is being used. MNP4 can use up to 256 byte packets, with MNP5 compression increasing that up to about 500 bytes. V.42 can use packets up to 4096 bytes in length, with V.42bis boosting that up to 16,000 bytes. Of course, the REAL data burst lengths after decompression will vary, and probably won't be as large as the numbers I've stated here. My point is that the receiving computer will receive bursts of data at full speed, and those bursts can be fairly large in size. If the computer can't handle that much data in one burst, then it will drop data on the floor and your statement will be untrue. > >Floyd L. Davidson | Alascom, Inc. pays me, |UA Fairbanks Institute of Marine >floyd@ims.alaska.edu| but not for opinions. |Science suffers me as a guest. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
floyd@ims.alaska.edu (Floyd Davidson) (05/20/91)
In article <1991May19.190618.14548@netcom.COM> gandrews@netcom.COM (Greg Andrews) writes: > >Hello. I'm here to tell you that it WILL when error correction is active. >It doesn't send HFC signals, to be sure. But it does send flow control >signals ("messages" is a better term) through the error correction protocol. > It won't send HFC signals, which is what I said. >> >>Even at 2400 bps between modems one could still have a problem if the The "problem" I was talking about is losing data. >>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. >> > >Again, when error correction is active, you'll get exactly that. The data >would come across the phone line in a packet, and the receiving modem can't >release that data until the whole packet arrives intact. As soon as the >modem checks the packet for errors, it releases the data to the computer at >the full speed of the RS232 interface. 19.2 Kbps, in your example. > >Thus the computer receives data at an AVERAGE of 2400 bps, but the computer's >ability to handle the data rests on how it can handle data in bursts as well >as over the average. With error correction active, the modem would feed >data to the computer in full speed bursts with pauses between each burst. >The amount of data in each burst will depend on the data flow and which error >correction protocol is being used. MNP4 can use up to 256 byte packets, with >MNP5 compression increasing that up to about 500 bytes. V.42 can use packets >up to 4096 bytes in length, with V.42bis boosting that up to 16,000 bytes. > >Of course, the REAL data burst lengths after decompression will vary, and >probably won't be as large as the numbers I've stated here. My point is that >the receiving computer will receive bursts of data at full speed, and those >bursts can be fairly large in size. If the computer can't handle that much >data in one burst, then it will drop data on the floor and >your statement will be untrue. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ My statement was that it would lose the data, which as you've pointed out is true. Thanks for posting Greg. My first post on this suggested that it be taken to comp.dcom.modems and you are specifically the person who posts to that group that I was thinking of... Floyd -- Floyd L. Davidson | Alascom, Inc. pays me, |UA Fairbanks Institute of Marine floyd@ims.alaska.edu| but not for opinions. |Science suffers me as a guest.
gandrews@netcom.COM (Greg Andrews) (05/20/91)
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 | `------------------------------------------------------------------------'
mhw@fithp (Marc Weinstein) (05/20/91)
From article <2825@public.BTR.COM>, by thad@public.BTR.COM (Thaddeus P. Floryan): > In article <1991May19.030549.3983@ims.alaska.edu> floyd@ims.alaska.edu (Floyd Davidson) writes: > {comments re: HFC on the 3B1 per the extractions:} > >> HFC doesn't have anything to do with the rate of data transfer >> between the modems. The sending modem is NOT going to detect >> anything as a result of the receiving modem asserting HFC. >> [...] >> I would suggest that anyone else who wants further >> information on this should bring it up in the comp.dcom.modems >> group. > > Outgoing HFC works just fine on the 3B1, both over hardlines and modems. Thus > I disagree with the comment above re: "...sending modem is NOT going to detect > anything..." because calling from my office at 2400 baud into a T2500 connected > to my 3B1 (fixed at 9600 baud) works just fine ... the 3B1 does "somehow" > detect my office computer's HFC signal to STOP to prevent its (the office > computer's) buffer from overflowing when the 3B1 is sending at 9600 baud but > the office computer is receiving at 2400 baud. Magic? Swinging dead chickens > over one's head while dancing under a full moon in one's Jockey shorts? Dunno. No magic involved. Unless you're using plain, vanilla V.22bis for your 2400 baud connection. Then, I dunno. Both MNP and V.42 error-correction protocols support Flow Control. I'm not sure how it's done, but the protocols handle it. Modems which implement these protocols typically REQUIRE HFC on the computer, since it then becomes likely that the modems will detect and exert flow control. If your system doesn't recognize it, you're screwed. If you support HFC and are using these protocols, then you have computer-to-computer flow control. So, unless the T2500 doesn't support the protocols, you can get rid of the dead chickens. Or, have them for dinner. -- Marc Weinstein {simon,royko,tellab5}!linac!fithp!mhw Elmhurst, IL -or- {internet host}!linac.fnal.gov!fithp!mhw