rick@pcrat.UUCP (Rick Richardson) (02/20/88)
[ Regarding null modem design ] In article <8802180550.AA09815@ucbvax.Berkeley.EDU> RAF@NIHCU.BITNET ("Roger Fajman") writes: >Crossing pins 4 and 5 (Request To Send and Clear To Send, >respectively) makes no sense to me. As has been pointed out, there are many, many ways to make a null modem. The cross of 4 and 5 is 'best' when you have devices which implement the so called "EIA Flow Control" (aka hardware flow control). Here, CTS controls the flow from DTE to DCE, RTS controls the flow from DCE to DTE. In this scheme, there is no longer any correlation between the assertion of RTS and the reply with CTS. Some manufacturers use DTR to do essentially what the RTS signal does in the above explanation. This, to me, is ugly since you lose a useful indication (that there is a live DTE out there). The lossage of the RTS-CTS line turnaround protocol, on the other hand, is minor. [Triggers my Flow Control Button in general...] At any rate, the need for "EIA Flow Control" is evident in these days of packet switched data, be it between packetized modems, or ISDN TE's. If you don't have EIA flow control, you'll find it just about impossible to run an interactive session over one of these facilities, and then switch in mid-session to a file transfer using XMODEM, YMODEM, or any other protocol which uses all 8 bits. Without EIA flow control, your only option is "no flow control" for the whole session -- and that means probable data lossage. If you've never seen how frustrating this can be, just do this: get yourself an aging VT100, log in to UNIX and turn off Xon/Xoff flow control. Take out all delays in the termcap/terminfo entry, and try scrolling around in a file with a screen editor. Now, even if you have a spiffy PC that can run 40 megabaud without flow control talking to a VAX 88Million, you may still have to contend with a network between you and the VAX that can't (instantaneously) keep up. You get the same effect. [ Now blast the DTE folk for ignoring DCE needs ] The unfortunate situation is that, while many DCE manufacturers have seen fit to provide for EIA Flow Control, the DTE side of the house has a lot of catching up to do. And until they do, you may find yourself saying: "Well, I have a ('Blazer, ISDN line, etc.) that can move data at (19.2K, 38.4K, etc.), but I only run it at 9.6" -- Rick Richardson, President, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days) uunet!pcrat!rick
RAF@NIHCU.BITNET ("Roger Fajman") (02/23/88)
> As has been pointed out, there are many, many ways to make a null modem. > The cross of 4 and 5 is 'best' when you have devices which implement > the so called "EIA Flow Control" (aka hardware flow control). Here, > CTS controls the flow from DTE to DCE, RTS controls the flow from > DCE to DTE. In this scheme, there is no longer any correlation between > the assertion of RTS and the reply with CTS. Interesting. What are some examples of devices that work that way? I haven't run across any, while I have seen a lot that use DTR. Does the RS-232C standard really cover this use of Request To Send? I haven't read it lately, but judging from the name of the pin, I suspect not. If that is true, then it is something of a misnomer to call it "EIA flow control." The normal use of RTS/CTS that the DTE brings up RTS when it wants to transmit and receives CTS from the DCE when it is ok to do so. It's important with half duplex modems. Yes, of course there are many ways to make a null modem. What works in one case may not work in another.
rick@pcrat.UUCP (Rick Richardson) (02/23/88)
In article <8802222331.AA03700@ucbvax.Berkeley.EDU> RAF@NIHCU.BITNET ("Roger Fajman") writes: >> As has been pointed out, there are many, many ways to make a null modem. >> The cross of 4 and 5 is 'best' when you have devices which implement >> the so called "EIA Flow Control" (aka hardware flow control). Here, >> CTS controls the flow from DTE to DCE, RTS controls the flow from >> DCE to DTE. In this scheme, there is no longer any correlation between >> the assertion of RTS and the reply with CTS. > >Interesting. What are some examples of devices that work that way? >I haven't run across any, while I have seen a lot that use DTR. > >Does the RS-232C standard really cover this use of Request To Send? >I haven't read it lately, but judging from the name of the pin, I >suspect not. If that is true, then it is something of a misnomer to >call it "EIA flow control." The normal use of RTS/CTS that the DTE >brings up RTS when it wants to transmit and receives CTS from the >DCE when it is ok to do so. It's important with half duplex modems. I don't believe this usage is in any standard. And I agree that the name is poor. However, as half-duplex modems are disappearing, and there's a clear need for full duplex out-of-band flow control, this scheme has become popular. I've heard this called "hardware flow control", "EIA flow control", and "RTS/CTS full duplex flow control". Several DCEs, including the 'Blazer implement this. AT&T's ISDN data modules implement this. I'm told NCR, Pyramid, and Gould have it available on some DTE products. I think that the Procomm Plus terminal emulator for the IBM PC implements it (though I'm not at all convinced it can be done reliably with an 8250 and software). There's probably more. Even though the DTR drop was a pre-existing method of faking out-of-band flow control from the DTE back to the DCE, it fails miserably in the following (common) configuration: You've got a DCE that moves data via packets. This could be a packetizing modem, or an ISDN data module that can accept X.25 data calls on either the 16K or the 64K channel. The interface speed might be locked at 9.6K or 19.2K, or could vary depending upon the whims of an incoming caller. Your DTE computer will need flow control both directions since the caller/network/DCE could instanteously and/or on average be running either faster OR slower than your DTE computer is. You can't use DTR to signal the DCE to slow down, since, presumably, you'd want the DCE to answer calls ONLY if there is a live DTE (maybe a "getty") attached. You also want the DCE to drop the call (and maybe reset parameters) if the DTE drops DTR. If I were buying a computer today, and looking toward the future of data communications, I'd bug the vendor about their support and or plans for support of (fill in favorite name) flow control. -- Rick Richardson, President, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
paul@vixie.UUCP (Paul Vixie Esq) (02/24/88)
In <8802222331.AA03700@ucbvax.Berkeley.EDU> RAF@NIHCU.BITNET ("Roger Fajman"):
## As has been pointed out, there are many, many ways to make a null modem.
## The cross of 4 and 5 is 'best' when you have devices which implement
## the so called "EIA Flow Control" (aka hardware flow control). Here,
## CTS controls the flow from DTE to DCE, RTS controls the flow from
## DCE to DTE. In this scheme, there is no longer any correlation between
## the assertion of RTS and the reply with CTS.
#
#Interesting. What are some examples of devices that work that way?
#I haven't run across any, while I have seen a lot that use DTR.
The Telebit Trailblazer can work this way, if you ask it to. My Symmetric
375 can do it. The Bell Technologies ICC multiport serial card can do it.
The Ann Arbor Ambassador can do it. Ungermann-Bass networked serial-port
controllers have a special mode that does exactly this.
#Does the RS-232C standard really cover this use of Request To Send?
No. The standard says that RTS/CTS is for controlling the direction of data
transfer on a modem that can only transmit one direction at a time. However,
there are a lot of devices that can transmit in BOTH directions at a time, and
there is a Real Need for 8-bit transparency. In such applications, the need
for 8-bit transparency and full modem control (DTR/DCD/DSR) are much greater
than the (non-existent) need for modem turn-around -- the modem doesn't turn
around.
I bought several "Modem Communications Bibles" to hopefully learn about how
to make cables for a Bell Technologies ICC card, and none of them said any-
thing about this "full duplex" use of RTS/CTS. It very desperately needs to
become an official standard, since it is in very wide use as an unofficial
one. In the Ungermann-Bass product line, there is a configuration menu item
just for this. There is another for the RTS/CTS used in half-duplex modems.
In short, Everybody Does It This Way, so could somebody please document it
in an IEEE or ANSI spec somewhere?
--
Paul A Vixie Esq
paul%vixie@uunet.uu.net
{uunet,ptsfa,hoptoad}!vixie!paul
San Francisco, (415) 647-7023roy@phri.UUCP (Roy Smith) (02/24/88)
In article <825@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: [regarding using RTS/CTS as flow control, contrary to what RS-232 says] > It very desperately needs to become an official standard, since it is in > very wide use as an unofficial one. [...] In short, Everybody Does It > This Way, so could somebody please document it in an IEEE or ANSI spec > somewhere? Hear, hear! I don't know how common half-duplex modems (which need RTS/CTS to work as RS-232 says they should) really are, but in the 13 or so years that I've been using modems, I have never (knowingly) used or seen a single one. What I have seen is full-duplex modems (or at least modems which pretend to be full duplex), terminals, multiplexers, port selectors, and computer ports running at speeds from 110 to 19,200 bps, often with composite paths connecting several of the above at different bit rates, all with a desperate need for reliable out-of-band flow control. What I also see are manufacturers who are acutely aware of this need groping around in the darkness to try and coerce available signals into doing things they were never intended to do. Clearly, there needs to be some official written standard which includes hardware flow control for RS-232ish circuits. Unofficial RTS/CTS flow control sucks. Unofficial DTR flow control sucks. XON/XOFF flow control sucks. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
grr@cbmvax.UUCP (George Robbins) (02/25/88)
In article <3158@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > In article <825@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: > [regarding using RTS/CTS as flow control, contrary to what RS-232 says] > > It very desperately needs to become an official standard, since it is in > > very wide use as an unofficial one. [...] In short, Everybody Does It > > This Way, so could somebody please document it in an IEEE or ANSI spec > > somewhere? > > Hear, hear! I don't know how common half-duplex modems (which need > RTS/CTS to work as RS-232 says they should) really are, but in the 13 or so > years that I've been using modems, I have never (knowingly) used or seen a > single one... If you've never seen one, then you have a case of tunnel blindness from working with dial-up async connections to the exclusion of the greater world of datacomm. 8-) There are still zillions of half-duplex 1200 baud modems doing their thing in the business world, and a whole regime of multi-drop and two-wire leased-line controlled carrier applications. What this means is you can't just arbitrarily change the standard so that RTS has a radically different and pretty much incompatible definition. You could of course propose an alternate optional function that happens to share the same pin(s). You also need to define how the RTS and CTS pins are to be interpreted in this new order. Do they mean stop/abort character, stop at end of current character or stop when the software gets around to noticing a status change? In the latter case, should there be any kind of (optional) overrun/error indication defined? I suppose proposal the the proper standards organization would be in order, although the RS232 standard usually only gets changed after everybody is acutally doing something different... -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jerry@oliveb.olivetti.com (Jerry Aguirre) (02/26/88)
In article <3158@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In article <825@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: >[regarding using RTS/CTS as flow control, contrary to what RS-232 says] >> It very desperately needs to become an official standard, since it is in >> very wide use as an unofficial one. [...] In short, Everybody Does It >> This Way, so could somebody please document it in an IEEE or ANSI spec >> somewhere? > > Clearly, there needs to be some official written standard which >includes hardware flow control for RS-232ish circuits. Unofficial RTS/CTS >flow control sucks. Unofficial DTR flow control sucks. XON/XOFF flow >control sucks. I agree that flow control should be standardized. Having to make special cables so that CTS can be coupled to DTR is a pain. (And then there is Data General where CTS stops output on the next bit instead of on a character boundry.) But it is important to remember that whatever gets specified is only going to be an option for devices that are able to do flow control. With so may of our connections being buffered intelegent boxes today is is easy to think that everything should be able to do flow control. While a packetized modem like the TrailBlazer, with more power than some computers, can easily do it many modems and other devices just can not. The best an unbuffered device such as a modem or data switch will be able to do is to pass the flow control information to the device on the other end. This requires that it have a channel available to carry the flow control signals to the other end. With packetized channels such as the Blazer and terminal servers it is easy to piggyback the flow control in with the data. But many communications devices have just the single channel. Adding a reverse channel means either creating another carrier frequency or multiplexing it in with the data. Either solution means added expense. Some of the older modems used to have a seperate channel. If you check the rs232 spec. you will find that it has a "secondary channel" that even has its own modem control signals. I remember reading the manual for a modem that supported this. The secondary channel was good for 5 bits per second, just right for flow control. Using the secondary transmit and secondary receive for flow control makes more sense, within the rs232 spec., than using RTS and CTS. However few modems seem to support the secondary channel. In practice manufacturers usually add flow control after the product has already been designed. It is then that they find that users are unwilling to have their million dollar computer busy-wait on a slow peripheral. They then look at their interface and notice that some of the modem control signals, originally added out of superstition, arn't really being used and can be subverted for flow control. Using any other pins would mean changing the hardware and would cost too much. Even with a buffered device, like the TrailBlazer, flow control should really be end to end. If the final consumer of the data can't signal all the way back to what is generating the data then data can be lost. If even one part of the path can't support flow control then it won't be end to end. The future doesn't look good.
SNELSON@STL-HOST1.ARPA (03/01/88)
The following is quoted for EIA STANDARD RS-232-C Interface Between Data
Terminal Equipment and Data Communications Equipment Employing Serial
Binary Interchange.
In the forward it warns that a revised version of ISO International Standard
2110-1972 introduces some pin assignment incompatibilities with RS-323-C.
Section 4.4
Circuit CA - Request to Send (C.C.I.T.T. 105) [Recommendation V.24]
Direction: TO data communications equipment
This circuit is used to condition the local data communications equipment for
data transmission and, on a half duplex channel, to control the direction of
data transmission of the local data communication equipment.
On one way only channels or duplex channels, the ON condition maintains the
data communication equipment in the transmit mode. The OFF condition maintains
the data communication equipment in a non-transmit mode.
On a half duplex channel, the ON condition maintains the data communication
equipment in the transmit mode and inhibits the receive mode. The OFF
condition maintains the data communication equiment in the receive mode.
A transition form OFF to ON instructs the data communication equipment to
enter the transmit code [possibly this should read mode?-a printer error?]
(see Section 6.8). The data communication equipment responds by taking such
action as may be necessary and indicates completion of such actions by turning
ON Circuit CB (Clear to Send), thereby indicating to the data terminal
equipment that data may be transferred across the interface point on inter-
change Circuit BA (Transmitted Data).
A transition from ON to OFF instructs the data communication equipment to
complete the transmission of all data which has previously transferred across
the interface point on interchange Circuit BA and then assume a non-transmit
mode or a receive mode as appropriate. The data communications equipment
responds to this instruction by turning OFF Circuit CB (Clear to Send)
when it is prepared to again respond to a subsequent ON condition of Circuit
CA.
NOTE: A non-transmit mode does not imply that all line signals have been
removed from the communication channel. See section 6.8.
When Circuit CA is turned OFF, it shall not be turned ON again until Circuit
CB has been turned OFF by the data communication equipment.
An ON condition is required on Circuit CA as well as on Circuit CB, Circuit
CC (Data Set Ready) and, where implemented, Circuit CD (Data Terminal Ready)
whenever the data terminal equipment transfers data across the interface on
interchange Circuit BA.
It is permissible to turn Circuit CA ON at any time when Circuit CB is OFF
regardsless of the condition of any other interchange circuit.
Circuit CB - Clear to Send (C.C.I.T.T. 106)
Direction: FROM data communication equipment
Signals on this circuit are generated by the data communication equipment
to indicate whether or not the data set is ready to transmit data.
The ON condition together with the ON condition on interchange circuits
CA, CC and, where impletment, CD, is an indication to the data terminal
equipment that signals presented on Circuit BA (Transmitted Data) will be
transmitted to the communication channel.
The OFF condition is an indication to the data terminal equipment that it
should not transfer data across the interface on interchange Circuit BA.
The ON condition of Circuit CB is a response to the occurrence of a
simultaneous ON condition on Circuits CC (Data Set Ready) and Circuit CA
(Request to Send), delayed as may be appropriate to the data communications
equipment for establishing a data communication channel (including the
removal of the MARK HOLD clamp from the Received Data interchange circuit of
the remote data set) to a remote data terminal equipment.
Where Circuit CA (Request to Send) is not implemented in the data communication
equipment with transmitting capability, Circuit CA shall be assumed to be in
the ON condition at all times, and circuit CB shall respond accordingly.
Section 6.8 The turning ON of circuit CA (Request to Send) does not
necessarily imply the turning ON of a line signal on the communication channel.
Some data sets might not have a line signal as it is understood in this
standard, e.g. the signal can be modified digital base-band signal.
Conversely, in data sets which do transmit a "line signal", the turning OFF
of Circuit CA does not necessarily command the removal of that line signal
from the communication channel. On a duplex channel, the data set might
autonomously transmit a training signal to hold AGC Circuits or automatic
equalizers in adjustment, or to keep timing locked (synchronized) when circuit
CA is OFF.
It is not within the scope of this standard to specify in detail what occurs
on the communication channel (line) side of the data communication equipment.
Therefore the definition for Circuit CA uses the terminology "assume the
transmit mode" intentionally avoiding reference to "carrier" or "line signals".
However, the continued requirement for multipoint systems is recognized. Data
sets intended for this type of operation should permit the sharing of a
communcation channel by more that one data set transmitter and should, when
in a non-transmit mode, place no signal on the communcation channel which
might interfere with the transmission from another data set in the network.
end of quote.
There are several related standards
RS-269
RS-334
RS-363
RS-366 Interface Between Data Terminal Equipment and Automatic Calling
Equipment for Data Communication Equipment.
RS-404
RS-422
RS-423
RS-449
I personally think it is a bad practice to tie two or more drivers from
one interface to a single receiver on another interface.
XON/XOFF has a major problem in that it does not specify how soon the
transmitting device has to stop sending upon receipt of an XOFF command.
And there are several permutations of who is issuing XOFF and to whom
and in a multi-link connection it is sure not clear what, or when, or
who should stop sending and intercept the XOFF command before it shuts everything
down. With all the possible delays, including propagation, getting XOFF
to where the stoppee wants a device or protocol to stop sending, XOFF
in band may not be a viable solution. I see on some of the other mailing
lists some real sharp people addressing flow control. But I don't think
they want to worry about the electrical interface.
One additional thought. Some of this cutrate dial up service may be
32kbps voice or less. This may be fine for voice and some low speed
data, but if you are trying to move higher that 4800 bps data over
one of these cheepoes you are going to be in a world of hurt.
Regards,
Steve