csquared@ccwf.cc.utexas.edu (Randy Clarke) (05/21/91)
(A humble request to the net.modem.gurus)
We're currently trying to set up some v.42bis modems on our Xyplex
terminal server at work. The problem we've run into is this: Apparently,
compression only works if RTS/CTS flow control is available. As it stands
now, the Xyplex does not support this form of flow control (No pin outs
on the RJ-45 connector). My question is this: Why doesn't compression
work with standard XON/XOFF software control? From what I've read, it
has something to do with setting up a sychronous connection between the
two modems. Could someone please explain what kind of handshaking takes
place to make hardware flow control necessary or at least point me to
a FAQ file which explains v.42bis compression in some detail.
Thanks,
Randal C. Clarke
Zycor/Landmark Inc. rcc@zycor.lgc.com
220 Foremost Dr clarker@cs.utexas.edu
Austin, TX 78745 csquared@cc.utexas.edu
Phone: (512) 282-6699gandrews@netcom.COM (Greg Andrews) (05/21/91)
In article <49273@ut-emx.uucp> csquared@ccwf.cc.utexas.edu (Randy Clarke) writes: >(A humble request to the net.modem.gurus) > > We're currently trying to set up some v.42bis modems on our Xyplex >terminal server at work. The problem we've run into is this: Apparently, >compression only works if RTS/CTS flow control is available. > With all the modems that I'm familiar with, that is not true. Compression does not require hardware flow control. Matter of fact, compression doesn't require ANY flow control, in and of itself. The real inter-relationship is a bit different. To illustrate: a) Modem compression requires that data be pumped into the modem faster than the modem could pump it out (if compression weren't active). In other words, the RS232 port speed should be faster than the modem-to- modem connection speed. Otherwise, compression wouldn't give you any boost in throughput. b) Since real world conditions control the data transfer process, some data may not be as compressible as other data. Also, the modems may encounter impairments in the phone line. Both of these conditions may cause the modems to transmit data slower than expected. c) If the modems can't transmit as fast as expected, they may need to tell the computers to pause while the modems 'catch up'. The method where the modems tell the computer to pause is Flow Control. Flow control is NOT required when the port speed is faster than the connection speed, but it is STRONGLY recommended. The modems don't care which method of flow control you decide to use - as long as it works. So you see that compression relies upon a faster RS232 port speed, and a faster port speed works best with flow control. However none of those require one particular method of flow control over another, as long as the chosen method works correctly with the computer. However, there is another consideration here. It is not directly related to compression, so I didn't include it in my three point summary above. That other consideration is Data Transparency. Data Transparency is the idea that the modems (or any device) will pass your data through without altering it, and without mis-interpreting it. Using XON/XOFF flow control in the modems is not the most transparent mode, because the modems will place special meaning on the XON and XOFF characters. If an XON appears in the middle of your data, the modem will probably swallow it because the modem was told that XONs and XOFFs are flow control commands and not data characters. Imagine what an XOFF character would do. The modem will stop returning the other system's data! If the data that is exchanged between your systems will never pass XON or XOFF as data, then that's not a problem. XON and XOFF would appear only as flow control commands, so it's safe for the modems to react to them as such. However, if XON or XOFF bytes would appear as part of the data (as they do in the XMODEM, YMODEM, or UUCP "g" file transfer protocols), then XON/XOFF flow control will cause trouble. Hardware flow control has the advantage of leaving the modems in a completely transparent state. They don't use characters as start/stop commands, so they won't mis-interpret any of the data the computers send through them. To summarize, Compression doesn't *require* hardware flow control, but it's the recommended way to go. > Randal C. Clarke -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
tnixon@hayes.uucp (05/21/91)
In article <49273@ut-emx.uucp>, csquared@ccwf.cc.utexas.edu (Randy Clarke) writes: > We're currently trying to set up some v.42bis modems on our Xyplex > terminal server at work. The problem we've run into is this: Apparently, > compression only works if RTS/CTS flow control is available. As it stands > now, the Xyplex does not support this form of flow control (No pin outs > on the RJ-45 connector). My question is this: Why doesn't compression > work with standard XON/XOFF software control? From what I've read, it > has something to do with setting up a sychronous connection between the > two modems. Could someone please explain what kind of handshaking takes > place to make hardware flow control necessary or at least point me to > a FAQ file which explains v.42bis compression in some detail. There's no reason why data compression wouldn't work with XON/XOFF flow control instead of RTS/CTS, or even with no flow control at all (although you'd risk losing data in that case). The reason RTS/CTS is _preferred_ (but not _mandatory_) is that it is fully transparent to the type of data you're sending -- you can send the XON and XOFF characters as data, without them interfering with the local flow control mechanism. But so long as you never transfer XON or XOFF as data (meaning, you use file transfer protocols such as Kermit or ZMODEM that transparentize these characters), then there's no reason why you can't use XON/XOFF flow control with modems that have error control and data compression. If the particular modems you have happen to not support XON/XOFF flow control while V.42bis is being used, then that is a flaw in the design of THOSE modems. All Hayes V.42bis modems, and the vast majority of V.42bis modems from other manufacturers, DO support XON/XOFF protocol along with V.42bis data compression. -- Toby -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
root@zswamp.uucp (Geoffrey Welsh) (05/23/91)
In a letter to All, Randy Clarke (csquared@ccwf.cc.utexas.edu ) wrote: >The problem we've run into is this: Apparently, >compression only works if RTS/CTS flow control is available. Umm, that's a bit misleading. It implies that turning off flow control also switches data compression off, which *might* be the case but in all probability isn't. Flow control allows you to speak to the modem at speeds exceeding the actual link speed without fear of overrunning the modem's buffers. This is important if you expect the modem to compress your data and achieve higher throughput, since the modem can't transmit data any faster than you send it to the modem in the first place. So even if a 9600 bps modem with data compression is able to send your ASCII text at 1700 CPS, a computer stuck at 9600 bps to ensure integrity will never see more than 960 CPS (minus some overhead). >My question is this: Why doesn't compression work with >standard XON/XOFF software control? Unless you have really oddball modems, it should. I've done it with several brands. >From what I've read, it has something to do with setting >up a sychronous connection between the two modems. Most error-correction protocols (which serve as foundations for data compression protocols) don't use synchronous framing (i.e. they strip start and stop bits), giving you an incidental 20% boost in performance *before* data compression... *IF* you are talking to your modem at a speed higher than the reported physical connect speed. First of all, tell your modem *not* to adjust "DTE rate" (its RS-232 port speed) when it makes a connection, and tell your software not to adjust to the reported connect speed. Now configure your RS-232 port to operate at the modem's highest supported RS-232 speed (for newer USRobotics Couriers and most V.32bis, that's 38,400 bps; for most 9600+ bps modems, 19,200 bps; for 2400 bps modems, that's usually 9600 bps). This is known as 'locking your port speed'. Now simply configure your host computer and your modem to use the same type of handshaking (RTS/CTS hardware, XON/XOFF software, or ENQ/ACK software)... I suspect that you have this correct already. -- Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root 602-66 Mooregate Crescent, Kitchener, ON, N2M 5E6 Canada (519)741-9553 "He who claims to know everything can't possibly know much" -me