gandrews@netcom.COM (Greg Andrews) (04/10/91)
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 | `------------------------------------------------------------------------'
pjh@mccc.edu (Pete Holsberg) (04/12/91)
In article <1991Apr10.010317.22511@netcom.COM> gandrews@netcom.COM (Greg Andrews) writes: =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) Aw, you found me out! And please *do* comment. That was really the point of my posting, because they found that certain programs ran MUCH faster when they did not use RTS/CTS (over a null modem) that when they did!! =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. Sure, that's what I've been doing. No wonder I didn't have any trouble! ;-) Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91
gandrews@netcom.COM (Greg Andrews) (04/14/91)
In article <1991Apr11.180712.1779@mccc.edu> pjh@mccc.edu (Pete Holsberg) writes: >In article <1991Apr10.010317.22511@netcom.COM> gandrews@netcom.COM (Greg Andrews) writes: >=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. >=> >= >=(sounds like the PC Mag review - no comment) > >Aw, you found me out! And please *do* comment. That was really the >point of my posting, because they found that certain programs ran MUCH >faster when they did not use RTS/CTS (over a null modem) that when they did!! > After the modem review in the fall where PC Mag said the T2500 had trouble passing data across impaired lines in PEP mode (remember the resulting discussion here?), and the recent V.22bis modem review where three different modems all registered ~230 cps transfer rate across 'average' phone lines on a compressed file with an MNP5 connection, well... I don't put my faith in PC Mag's test results. Their articles are getting better as far as having fewer technical mistakes, but I still entertain doubts about their testing competence. You asked for my opinion - you got it. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'