dd@ariel.unm.edu (05/26/89)
I am about to use a CISCO terminal server in a new application - to front and a group of bit rate agile modems. I would appreciate hearing good and bad comments regarding CISCO's support of this type of capability. Thank you for your assistance! Don Doerner dd@ariel.unm.edu University of New Mexico CIRT 2701 Campus Blvd, NE Albuquerque, NM, 87131 (505) 277-8036
ron@ron.rutgers.edu (Ron Natalie) (05/27/89)
> I am about to use a CISCO terminal server in a new application - to front > and a group of bit rate agile modems. I would appreciate hearing good and > bad comments regarding CISCO's support of this type of capability. If you're talking about synchronous ports, there is no problem. The Cisco will follow the clock rate from disgustingly slow up to (and beyond presumably) T1. If you're talking async modems with some sort of fall back, no computer or terminal server can deal with this unless you give it some external indication of the speed changing. The typical way of handling slick modems that have variable effective transfer speeds is to just set the rs-232 port to a high speed and use some flow control to handle the speed mismatch. Cisco can do flow control on either on one of the RS-232 spare pins or with XON/XOFF. It's configurable per port. -Ron
jeff@b11.ingr.com (Jeff Kilpatrick) (05/31/89)
In article <May.26.13.18.36.1989.214@ron.rutgers.edu>, ron@ron.rutgers.edu (Ron Natalie) writes: > speed mismatch. Cisco can do flow control on either on one of > the RS-232 spare pins or with XON/XOFF. It's configurable per ^^^^^^^^^^^^^^^^^^^^^ Do they support RTS/CTS or are they doing something proprietary(sp?)?
jeff@tramp.Colorado.EDU (Jefferson W. Christy) (05/31/89)
In article <5159@b11.ingr.com> jeff@b11.ingr.com (Jeff Kilpatrick) writes: >In article <May.26.13.18.36.1989.214@ron.rutgers.edu>, ron@ron.rutgers.edu (Ron Natalie) writes: > >> speed mismatch. Cisco can do flow control on either on one of >> the RS-232 spare pins or with XON/XOFF. It's configurable per > ^^^^^^^^^^^^^^^^^^^^^ > > Do they support RTS/CTS or are they doing something proprietary(sp?)? The ASM/2 terminal server from Cisco does support flow hardware flow control on RTS/CTS, if you don't need modem-style handshaking. If however, the line is configured to use modem control, then the CTS input is used for this purpose and hardware flow-control is not an option. The limiting factor is that each terminal line is supported on only six pins (RD, TD, GND, RI, DTR, and CTS). I might add that we use the ASM/2 to interface our async data switch (ISN) with our campus ethernet, and we have been very pleased with Cisco, both in terms of flexibility and reliability. Jeff Christy Computing and Network Services Univ. of Colo., Boulder _ /| Inet: jeff@tramp.colorado.edu \`o_O' uucp: ...!boulder!tramp!jeff ( ) U Just goes to show, you don't ever know...
ron@ron.rutgers.edu (Ron Natalie) (06/01/89)
>> the RS-232 spare pins or with XON/XOFF. It's configurable per > ^^^^^^^^^^^^^^^^^^^^^ > Do they support RTS/CTS or are they doing something proprietary(sp?)? There is no such thing as RTS/CTS flow control. Cisco does what you'd expect. They use the RTS pin as flow control in one direction and CTS as flow in the other. Actually, the CISCO doesn't know about RS-232 pins too much. There are six wires on each serial port. There are six wires to each serial port and there use depends on how the box is configured and how you wire them up the DB-25 (the box has a 50 pin AMPHENOL connector on the back for each eight lines). -Ron
goodloe@b11.ingr.com (Tony Goodloe) (06/05/89)
In article <May.31.13.57.52.1989.361@ron.rutgers.edu>, ron@ron.rutgers.edu (Ron Natalie) writes: > > Do they support RTS/CTS or are they doing something proprietary(sp?)? > There is no such thing as RTS/CTS flow control. Cisco does what you'd > expect. They use the RTS pin as flow control in one direction and CTS > as flow in the other. This is not what I would expect. The way RS-232 (and all the other specs I've read) work is that the DTE raises RTS and if the DCE is able to accect data, it raises CTS in response. When the DCE can't accept more data, it drops CTS. That sounds like RTS/CTS flow control to me. If they do something differently, it's proprietary. > -Ron -tony
henry@utzoo.uucp (Henry Spencer) (06/06/89)
In article <5187@b11.ingr.com> goodloe@b11.ingr.com (Tony Goodloe) writes: >This is not what I would expect. The way RS-232 (and all the other specs >I've read) work is that the DTE raises RTS and if the DCE is able to >accect data, it raises CTS in response. When the DCE can't accept more >data, it drops CTS. That sounds like RTS/CTS flow control to me... What most people mean by "RTS/CTS" flow control is using one line for flow control in one direction and the other for the other direction. At least that's my impression. This is, of course, nonstandard. So is the description above, though: CTS is not supposed to drop as long as RTS stays up. RTS is not "I have data for you", it is "start transmitter", and CTS correspondingly is "transmitter operating, send at will". The signals are meant for coordinating with half-duplex modems, which must be told when to transmit and when to listen. As far as I know, it is not kosher for the modem to unilaterally decide to stop transmitting; that is the host's decision. (Many modern half-duplex modems present a full-duplex interface to the host, with direction-switching handled between the two modems without host intervention, but that's a different story.) Unless things have changed since I learned this, RTS and CTS thus are not flow-control signals at all. Note that this is theory, as opposed to the facts of how they are actually used by many devices... -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu