Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!daver!dlb!netcom!gandrews From: gandrews@netcom.COM (Greg Andrews) Newsgroups: comp.unix.sysv386 Subject: Re: need for RTS/CTS at high speeds (was re: SCO RTS/CTS Setup) Summary: Depends on the type of data you send. Keywords: RTS/CTS Hardware Flow Telebit RS-232 Unix 386 SCO Message-ID: <1991Apr10.010317.22511@netcom.COM> Date: 10 Apr 91 01:03:17 GMT References: <1991Apr7.024322.4465@netcom.COM> <1991Apr8.173125.22219@mccc.edu> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 46 In article <1991Apr8.173125.22219@mccc.edu> pjh@mccc.edu (Pete Holsberg) writes: >A computer magazine recently tested a number of communications programs >at various speeds and published the results. They said that at higher >transfer rates (57.6K and 115.2K), they used RTS/CTS handshaking because >(I'm paraphrasing) that's what you had to use when you had high speed >modems. This puzzled me because I've been using Trailblazers at their >maximum speed for a couple of years now, with either no or XON/XOFF >handshaking. Could someone enlighten me? > (sounds like the PC Mag review - no comment) RTS/CTS is a lot faster than XON/XOFF. By that, I mean the computers can respond to RTS/CTS signals faster than XON/XOFF characters. This has two effects: (a) Data flow stops sooner preventing buffer overflow, and (b) Because of (a), comm software can raise the flow control threshold to allow more data to come in before making it stop. The first prevents errors that would slow down data transfer, and the second increases the efficiency of the data flow by increasing the amount of time the data flows vs the amount of time the data doesn't flow. It's faster because dropping an RS232 signal line can be accomplished in one or two bit periods (the time to transfer one bit at >38,400 bps). It requires ten bit periods to send an XOFF and a certain amount of time overhead while the transmitting computer figures out it got an XOFF and decides to stop transmitting. More important, it's a transparent form of flow control. Protocols like XMODEM and uucp can easily send XON and XOFF characters as part of the file data. If those bytes are interpreted as start/stop commands instead of file data, the protocol will encounter errors. If the channel uses RTS/CTS, the XON and XOFF bytes can pass transparently through and aren't misinterpreted. If the data flow across your TrailBlazers doesn't use XON/XOFF then you probably wouldn't have encountered the above problems with XON/XOFF. Running uucp transfers with PEP-mode spoofing in the TrailBlazers doesn't count because the modems automatically turn off their XON/XOFF control when the transfer begins. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'