lance@belltec.UUCP (Lance Norskog) (10/13/89)
Hey all you modem wizards! I have a peculiar question. Do old-style analog modems pass through the CTS/DTS signaling along with the data, or do they ignore it? If CTS/DTS is part of the spec'd behavior of modems, how is it handled with high-speed digitally buffered and processed modems? -- Lance C Norskog Sales Engineer, Streamlined Networks thinman@cup.portal.com: 415-659-1450
tcm@srhqla.SR.COM (Tim Meighan) (10/14/89)
In article <413@belltec.UUCP> lance@belltec.UUCP (Lance Norskog) writes: >I have a peculiar question. Do old-style analog modems pass through the >CTS/DTS signaling along with the data, or do they ignore it? If CTS/DTS >is part of the spec'd behavior of modems, how is it handled with high-speed >digitally buffered and processed modems? Well, it's not so peculiar, although you are mixing acronyms. RTS and CTS are lines usually used for flow control, while DTR (not DTS) is generally used for equipment control (like resetting a modem to make sure it hangs up the phone line). Also, you don't seem to have a good grasp of what flow control on serial ports is for -- these are NOT signals intended to be propagated through, like data, to appear at the remote modem's serial port. RTS and CTS are used to make sure that the flow of data between the modem and the LOCAL data producing equipment (computer, terminal, etc) is properly maintained without data loss. An example: your local modem connects to a remote modem at 300 baud, but the speed of the RS-232 link between your modem and your computer is at 1200 baud. Since your computer is sending chars into your modem faster than it can get them over the phone line, your modem has to be able to occasionally tell your computer to stop talking so it can get caught up. That's flow control, and that's what RTS and CTS are used for. All modems that support hardware flow control, old or new, work this same basic way. The method that modems use to exchange data on the analog side (the phone line) doesn't change the function of RTS/CTS on the serial port side. Tim Meighan SilentRadio "Guaranteed more reliable, with fewer working parts!"
Owens-Christopher@cs.yale.edu (Christopher Owens) (10/16/89)
In article <1180@srhqla.SR.COM>, tcm@srhqla (Tim Meighan) writes: > In article <413@belltec.UUCP> lance@belltec.UUCP (Lance Norskog) writes: > > >I have a peculiar question. Do old-style analog modems pass through the > >CTS/DTS signaling along with the data, or do they ignore it? If CTS/DTS > >is part of the spec'd behavior of modems, how is it handled with high-speed > >digitally buffered and processed modems? > > Well, it's not so peculiar, although you are mixing acronyms. RTS and CTS > are lines usually used for flow control, while DTR (not DTS) is generally > used for equipment control (like resetting a modem to make sure it hangs > up the phone line). Also, you don't seem to have a good grasp of what > flow control on serial ports is for -- these are NOT signals intended > to be propagated through, like data, to appear at the remote modem's > serial port. > > RTS and CTS are used to make sure that the flow of data between the modem > and the LOCAL data producing equipment (computer, terminal, etc) is properly > maintained without data loss. > [...] > All modems that support hardware flow control, old or new, work this same > basic way. The method that modems use to exchange data on the analog side > (the phone line) doesn't change the function of RTS/CTS on the serial > port side. There is something about RTS/CTS and modem links that I have never fully understood. My understanding of flow control is as follows. I'm sorry if I am mixing up RTS and CTS -- I don't have the reference handy. By RTS I mean the line from the DTE to the modem telling the modem that the DTE is ready to accept data. By CTS I mean the line from the modem to the DTE telling the DTE that the modem is ready to accept data. Let's say I am connected and configured at both ends to use RTS/CTS. Now if I am at the receiving end of a data transfer, and I find my input buffer filling, I will drop RTS, which tells my modem to stop sending characters to me. Now, presumably, the modem's internal buffer is going to fill up pretty fast, at which point it is going to want to send some kind of signal to the other modem to tell it to stop sending data down the communications line. The exact nature of this signal would depend upon the modem protocol, of course. If the other modem obeys this signal, then pretty soon its buffer is going to fill up, at which point it wants to signal the computer at its end to stop sending characters to it, presumably by dropping CTS. By this time I have emptied my input buffer, so I re-assert RTS, which tells my modem to start sending characters to me again. When my modem's buffer begins to empty, it sends a signal to the other modem to tell it to start sending data to it again, at which point its buffer begins to empty, and it turns on the flow at the far end by re-asserting CTS. So, according to my understanding, RTS and CTS are in some indirect sense passed through the telecommunications link in that, if the DTE at one end shuts off the flow from the modem, the modem at the other end will eventually shut off the flow from the DTE to which it is connected. Now what I don't understand is, what do the modems use for this mystery signal to communicate with each other? How sophisticated a protocol does one need to be using before this happens? Does a plain analog modem (e.g.: Bell 212) do anything of this kind? If not, what happens when one drops RTS at one end of the connection? To throw in an additional monkey wrench, what if one modem is configured to use rts/cts flow control, and the other is configured to use XON/XOFF. Assuming a modem protocol like, for example, MNP5, is everything sorted out correctly such that de-asserting RTS at one end will result in an XOFF being sent at the other end? My thanks to anyone who can explain this to me. /c
henry@utzoo.uucp (Henry Spencer) (10/17/89)
In article <413@belltec.UUCP> lance@belltec.UUCP (Lance Norskog) writes: >I have a peculiar question. Do old-style analog modems pass through the >CTS/DTS signaling along with the data, or do they ignore it? ... It's not clear what you're referring to, since there is no "DTS" line. In any case, CTS, RTS, DSR, and DTR (among others) are all for signalling between the *host* and the *modem*, not between the two hosts. So it is meaningless to speak of them being "passed through". And incidentally, none of them is a flow-control signal, despite popular misconceptions (and extensive non-standard use for that purpose). -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (10/18/89)
In article <2532@cs.yale.edu> Owens-Christopher@cs.yale.edu (Christopher Owens) writes: >... By RTS I mean the line from the DTE to the modem telling the >modem that the DTE is ready to accept data. By CTS I mean the line >from the modem to the DTE telling the DTE that the modem is ready to >accept data. Actually there are no such lines in the standards, although today's modems often use RTS and CTS for that purpose anyway... >Now if I am at the receiving end of a data transfer, and I find my >input buffer filling, I will drop RTS, which tells my modem to stop >sending characters to me. Now, presumably, the modem's internal >buffer is going to fill up pretty fast, at which point it is going to >want to send some kind of signal to the other modem to tell it to stop >sending data down the communications line... It wants to. However, it can't, in most of the standard modem protocols, because there is no such signal. If you can't accept data as fast as the other end sends it, you lose some of it. Simple as that. >So, according to my understanding, RTS and CTS are in some indirect >sense passed through the telecommunications link... Nope. Because RTS and CTS were *not* meant as flow-control signals, there is no provision for doing this in most modem protocols. I think Telebit's PEP will do it, but that's a very different story from the rest of the modem world. >... Does a plain >analog modem (e.g.: Bell 212) do anything of this kind? Minor clarification: Bell 212 is not a plain analog modem. To find a plain analog modem -- one which just passes the state of its input-data lines to the other end at all times -- you have to go back to Bell 103 at 300 baud. >If not, what >happens when one drops RTS at one end of the connection? In a standard modem, what happens if you drop RTS is that the modem either pays no attention or stops sending carrier. The standard purpose of RTS is to tell the modem "commence transmitting", and CTS is for it to tell you "I am transmitting, go ahead and send data". They are meant for half-duplex modems in which only one end can be transmitting carrier at a time. Old full-duplex modems either require RTS to be on at all times when connected, or ignore it entirely. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jeh@simpact.com (10/18/89)
In article <2532@cs.yale.edu>, Owens-Christopher@cs.yale.edu (Christopher Owens) writes: > There is something about RTS/CTS and modem links that I have never > fully understood. My understanding of flow control is as follows. > I'm sorry if I am mixing up RTS and CTS -- I don't have the reference > handy. By RTS I mean the line from the DTE to the modem telling the > modem that the DTE is ready to accept data. By CTS I mean the line > from the modem to the DTE telling the DTE that the modem is ready to > accept data. This is correct insofar as popular (nonstandard) usage is concerned, and we'll assume this for sake of argument. (According to RS232, RTS is indeed sourced by the DTE and read by the modem, but it means "modem, I want to send", not "modem, I can receive". A DTE using this protocol raises RTS when it wants to send data (ie when a write is queued to the modem port) and then waits for CTS from the modem before proceeding. CTS from the modem shouldn't be present in the absence of RTS from the DTE. (This was used primarily on old-style half-duplex modems (eg Bell 201) which had to do line turnarounds.... not unlike modern high-speed mostly-half-duplex modems. The difference is that the modern modems initiate a turnaround automatically upon receipt of data from the "wrong" DTE, rather than relying on RTS signalling.) > Let's say I am connected and configured at both ends to use RTS/CTS. > Now if I am at the receiving end of a data transfer, and I find my > input buffer filling, I will drop RTS, which tells my modem to stop > sending characters to me. Now, presumably, the modem's internal > buffer is going to fill up pretty fast, at which point it is going to > want to send some kind of signal to the other modem to tell it to stop > sending data down the communications line. Either that or it just stops sending acknowledgements to the other modem. > The exact nature of this > signal would depend upon the modem protocol, of course. If the other > modem obeys this signal, then pretty soon its buffer is going to fill > up, at which point it wants to signal the computer at its end to stop > sending characters to it, presumably by dropping CTS. By this time I > have emptied my input buffer, so I re-assert RTS, which tells my modem > to start sending characters to me again. When my modem's buffer > begins to empty, it sends a signal to the other modem to tell it to > start sending data to it again Or, more likely, it just starts sending ACKs again. > at which point its buffer begins to empty, > and it turns on the flow at the far end by re-asserting CTS. > > So, according to my understanding, RTS and CTS are in some indirect > sense passed through the telecommunications link in that, if the DTE > at one end shuts off the flow from the modem, the modem at the other > end will eventually shut off the flow from the DTE to which it is > connected. Yes, between similar modems which use this type of signalling. > Now what I don't understand is, what do the modems use for this > mystery signal to communicate with each other? I can't speak in the general case, but at least some modems in my experience encapsulate the user data into packets (with framing characters, CRC checksums, etc.). A "packet type" field in the packet header can be used to say "this packet contains no user data, rather it's a modem-to-modem supervisory message", and in that case other fields in the packet header tell what sort of message it is (ack, nak, whatever). It is also possible to use "alternate channel" techniques. The Trailblazers, when operating in PEP mode, divide the bandwidth into a number of subcarriers. One or more of these could be used for supervisory data. I don't know for certain if they actually work this way or not (it's really impossible to tell from the outside0. > How sophisticated a > protocol does one need to be using before this happens? The sophistication level must be at least 42. Seriously, I don't know how to answer this. I believe that MNP 5 and up will do it, but I'm not certain. Trailblazers in PEP mode do it. > Does a plain > analog modem (e.g.: Bell 212) do anything of this kind? If not, what > happens when one drops RTS at one end of the connection? No, they don't. A Bell 212 obeys the standard meaning of RTS (ie it means that the DTE wants to send). But being a true full-duplex modem there is no notion of line turnaround. Thus if you raise RTS, the modem will immediately raise CTS, and if you drop RTS, the modem will drop CTS. (But, being a full-duplex modem, I doubt that it will stop accepting data.) > To throw in > an additional monkey wrench, what if one modem is configured to use > rts/cts flow control, and the other is configured to use XON/XOFF. > Assuming a modem protocol like, for example, MNP5, is everything > sorted out correctly such that de-asserting RTS at one end will result > in an XOFF being sent at the other end? If everything is configured correctly, yes, this works. Of course, "interesting" situations develop if the DTE that's using rts/cts tries to send a data byte that just happens to look like either an xon or an xoff. I don't know whether the other DTE's modem, being configured for xon/xoff flow control, will refuse to pass this "inband data" to the DTE or not. If the byte does get to the DTE it will have no way of distinguishing this from an xon or xoff sent by the local modem for flow control purposes. --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh
casey@gauss.llnl.gov (Casey Leedom) (10/20/89)
| From: henry@utzoo.uucp (Henry Spencer) | | > From: Owens-Christopher@cs.yale.edu (Christopher Owens) | > | > ... Now, presumably, the modem's internal buffer is going to fill up | > pretty fast, at which point it is going to want to send some kind of | > signal to the other modem to tell it to stop sending data down the | > communications line... | | It wants to. However, it can't, in most of the standard modem protocols, | because there is no such signal. If you can't accept data as fast as the | other end sends it, you lose some of it. Simple as that. ... I think | Telebit's PEP will do it, but that's a very different story from the rest | of the modem world. This is a question I've been needing to deal with for a bit now and just haven't gotten around to it. I assumed that Telebit's PEP and Microcom's MNP would both have flow control provisions in the protocols because they're error controlling protocols, but Henry's letter calls that assumption into question. Does anyone know if two MNP modems (say running MNP5) have any way of throttling each other? It would be most inconvenient if they don't ... I'm running a GraphOn Optimax 200 X terminal at home over a pair of Telebit T2500s. The T2500s can overrun the GraphOn fairly easily. (I've been told there are new PROMs coming out for the Optimax 200 that speed up character drawing to about 22KCPS - it's currently somewhere around 16KCPS. I don't know if anything else will be faster.) Casey
chris@yarra.oz.au (Chris Jankowski) (10/20/89)
In article <36214@lll-winken.LLNL.GOV> casey@lll-crg.llnl.gov (Casey Leedom) writes: > | From: henry@utzoo.uucp (Henry Spencer) > | > | > From: Owens-Christopher@cs.yale.edu (Christopher Owens) > | > > | > ... Now, presumably, the modem's internal buffer is going to fill up > | > pretty fast, at which point it is going to want to send some kind of > | > signal to the other modem to tell it to stop sending data down the > | > communications line... > | > | It wants to. However, it can't, in most of the standard modem protocols, > | because there is no such signal. If you can't accept data as fast as the > | other end sends it, you lose some of it. Simple as that. ... I think > | Telebit's PEP will do it, but that's a very different story from the rest > | of the modem world. > > This is a question I've been needing to deal with for a bit now and > just haven't gotten around to it. I assumed that Telebit's PEP and > Microcom's MNP would both have flow control provisions in the protocols > because they're error controlling protocols, but Henry's letter calls > that assumption into question. > > Does anyone know if two MNP modems (say running MNP5) have any way of > throttling each other? It would be most inconvenient if they don't ... > I'm running a GraphOn Optimax 200 X terminal at home over a pair of > Telebit T2500s. The T2500s can overrun the GraphOn fairly easily. (I've > been told there are new PROMs coming out for the Optimax 200 that speed > up character drawing to about 22KCPS - it's currently somewhere around > 16KCPS. I don't know if anything else will be faster.) > > Casey I see the problem the following way. What you need is an out-of-band logical channel in the same physical stream of bits flowing through the line. 1. If you have any protocol using packets with a header there is nothing simpler than specify a special packet to do flow control. Both PEP and MNP5 certainly do it and this is even required for their own use due to the fact they have to handle loss/corruption of packets. Nearly always all devices having buffers of significant size will use some form of flow control. 2. If you do not use any packetised protocol you still can use some form of out-of-band signalling. There is a very well known and elegant technique called byte stuffing. It may be used to pass out-of-band signals although it had been invented for another purpose. I am actually suprised that no modem I know of uses it for the purpose. The reason is probably that once you have buffers and a processor to deal with flow control it is not that difficult to have a real packetised protocol. It is only more software in ROM. 3. If you do not do binary transfers you can still use standard XON/XOFF characters for flow control *between* modems. Some modems do it this way. Correct me if I am wrong. (I am not a comms expert) -m------- Chris Jankowski - Senior Systems Engineer chris@yarra.oz{.au} ---mmm----- Pyramid Technology Corporation Pty. Ltd. fax +61 3 820 0536 -----mmmmm--- 11th Floor, 14 Queens Road tel. +61 3 820 0711 -------mmmmmmm- Melbourne, Victoria, 3004 AUSTRALIA (03) 820 0711 ``If you're crossing the nation in a covered wagon, it's better to have four strong oxen than 100 chickens. Chickens are OK but we can't make them work together yet.'' - Ross Bott, Pyramid U.S., on multiprocessors at AUUGM '89.