das@trac2000.ueci.com (David Snyder) (06/13/91)
In article <1CE00001.hv3cvx@tbomb.ice.com>, time@ice.com (Tim Endres) writes:
-> This is definitely wrong. I would be very suspicious of my register
-> settings. Here are mine (S58 and S111 are important):
->
-> E1 F1 M0 Q0 T V1 W0 X1 Y0 &P0 &T4 Version GF7.00-T2500SA
-> S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006
-> S10=007 S11=070 S12=050 S18=000 S25=005 S26=000 S38=000
-> S41=000 S45=000 S47=004 S48=000 S49=000
-> S50=000 S51:254 S52:002 S54=000 S55=000 S56=017 S57=019 S58:000 S59=000
-> S61=150 S62=003 S63=001 S64=000 S65=000 S66=000 S67=000 S68=255 S69=000
-> S90=000 S91=000 S92:001 S93=008 S94=001 S95=000 S96=001 S97=000 S98=003
-> S100=000 S101=000 S102=000 S104=000 S105=001 S106=000 S107=020
-> S110:000 S111:030 S112=001
-> S120:016 S121=000 S130=002 S131:001
-> S150=000 S151=004 S152=001 S153=001 S154=000 S155=000 S157=000 S158=000
-> S160=010 S161=020 S162=002 S163=003 S164=007 S169=000 S255=000
Is it really a good idea to turn off ALL flow control? I have my S58 set to
"002" for Full RTS/CTS flow control. If I can speed throughput without data
loss, please let me know.
DAS
--
David A. Snyder @ UE&C - Catalytic in Philadelphia, PA
UUCP: ..!uunet!trac2000!das INTERNET: das@trac2000.ueci.comgandrews@netcom.COM (Greg Andrews) (06/14/91)
In article <1034@trac2000.ueci.com> das@trac2000.ueci.com (David Snyder) writes: >In article <1CE00001.hv3cvx@tbomb.ice.com>, time@ice.com (Tim Endres) writes: >-> >-> This is definitely wrong. I would be very suspicious of my register >-> settings. Here are mine (S58 and S111 are important): >-> >-> [unimportant parts of Tim's register dump deleted] >-> >-> E1 F1 M0 Q0 T V1 W0 X1 Y0 &P0 &T4 >-> >-> S50=000 S51:254 S52:002 S54=000 S55=000 S56=017 S57=019 S58:000 S59=000 >-> S61=150 S62=003 S63=001 S64=000 S65=000 S66=000 S67=000 S68=255 S69=000 >-> >-> S110:000 S111:030 S112=001 >-> S120:016 S121=000 S130=002 S131:001 > >Is it really a good idea to turn off ALL flow control? I have my S58 set to >"002" for Full RTS/CTS flow control. If I can speed throughput without data >loss, please let me know. > Actually the answer is both "No, it's not a good idea", and "Yes it may be a very good idea". The answer for your installation depends on exactly what kind of calls you receive and what flow control your system can handle. Turning all flow control off can be a very bad idea for interactive use in PEP mode and with other error corrected connections. Actions like listing a large directory or redrawing a screen (^L in vi) can overflow the modem's buffer. If the modem can't make the computer pause (flow control is completely disabled), then some of the data will be lost. However, it should be noted that Tim's settings have the port speed unlocked (S66=0), therefore the slower speed connections probably won't overrun the modem's buffer - the modem can empty itself as fast as the computer pumps data in, so no overflow occurs. In PEP mode, there is a greater chance of losing data, but Tim's callers may not have a problem with it. Now let's look at UUCP use. The UUCP "g" protocol definitely rules out XON/XOFF flow control in the modem. It just won't work when the modem is reacting to XON and XOFF characters. That leaves RTS/CTS flow control, or none at all. Tim's setup is on a Macintosh, I believe, and he may not be able to give up the DTR and DCD signals for use as RTS and CTS. Therefore he elected to disable flow control entirely and use a configuration that reduces the need for flow control (S66=0). If your system can support RTS/CTS flow control, then by all means use it! The modem will stay transparent to UUCP transfers, yet still have control over the data flow during your interactive sessions. I also see that Tim has his modem set to Q0 - an extremely unusual setting for a Unix system. Getty generally needs the modem to use Q4. So you see that modem configurations posted on the net may reflect the special needs of the article's author. You may not want to duplicate their configuration unless you have exactly the same needs as they do. One last side note on Telebit modems and UUCP transfers: There is an alternate flow control setting that may help. Setting S58=0 and S68=3 will let the modem stay transparent to XON and XOFF for UUCP transfers, while allowing the modem to use XON/XOFF flow control to make the computer pause. This may not work for everyone. >David A. Snyder @ UE&C - Catalytic in Philadelphia, PA -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
gandrews@netcom.COM (Greg Andrews) (06/15/91)
In article <1991Jun15.050908.21677@coplex.uucp> dean@coplex.uucp (Dean Brooks) writes: >gandrews@netcom.COM (Greg Andrews) writes: > >>In article <1034@trac2000.ueci.com> das@trac2000.ueci.com (David Snyder) writes: >>>In article <1CE00001.hv3cvx@tbomb.ice.com>, time@ice.com (Tim Endres) writes: > >>I also see that Tim has his modem set to Q0 - an extremely unusual setting >>for a Unix system. Getty generally needs the modem to use Q4. So you see >>that modem configurations posted on the net may reflect the special needs >>of the article's author. You may not want to duplicate their configuration >>unless you have exactly the same needs as they do. > >What? Since when has Q0 been an unusual setting for a UNIX system? On >most SYSV/BSD systems, Q0 is a *necessity*. Most gettys, regardless of >gendre, require a completely quiet modem; no result codes *OR* echoing >of characters. If yours system needs otherwise, then *that* is an >extremely unusual system. > You have your modem commands backwards. Q0 is "not quiet". Result codes are ENABLED. As you say, most Unix systems do not want result codes, therefore the setting would be Q1 on most modems, and Q4 on Telebits, as I said. > >Either that, or you are running a funky getty that changes its >behaviour depending upon result codes from the modem. > There has been talk of a "wrapper" around getty in the A/UX groups, so I surmise that Tim is using one of those. >dean@coplex.uucp (Dean Brooks) -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
time@ice.com (Tim Endres) (06/15/91)
In article <1034@trac2000.ueci.com>, das@trac2000.ueci.com (David Snyder) writes: > > Is it really a good idea to turn off ALL flow control? I have my S58 set to > "002" for Full RTS/CTS flow control. If I can speed throughput without data > loss, please let me know. UUCP G Protocol *is* flow control. This is what the whole sliding window protocol is all about. Anyways, it is no problem to turn off all flow control, but having hardware flow control probably helps a little in some cases. It is always more efficient to control flow by hardware, than to require UUCP to retransmit packets. However, in my case, tbomb is a Macintosh and it is not convenient to implement hardware flow control. tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208
time@ice.com (Tim Endres) (06/15/91)
In article <1991Jun15.050908.21677@coplex.uucp>, dean@coplex.uucp (Dean Brooks) writes: > What? Since when has Q0 been an unusual setting for a UNIX system? On > most SYSV/BSD systems, Q0 is a *necessity*. Most gettys, regardless of > gendre, require a completely quiet modem; no result codes *OR* echoing > of characters. If yours system needs otherwise, then *that* is an > extremely unusual system. You got confused. Q1 means quiet. Q0 means not quiet. I have Q0 because I am on a Macintosh, and I listen for "CONNECT" instead of watching the CD line. tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208
time@ice.com (Tim Endres) (06/15/91)
In article <1991Jun15.075331.9638@netcom.COM>, gandrews@netcom.COM (Greg Andrews) writes: > There has been talk of a "wrapper" around getty in the A/UX groups, > so I surmise that Tim is using one of those. I do not run under A/UX. I run under the MacOS. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208
devil@TECHUNIX.TECHNION.AC.IL (Gil Tene) (06/17/91)
In article <1034@trac2000.ueci.com> das@trac2000.ueci.com (David Snyder) writes: >In article <1CE00001.hv3cvx@tbomb.ice.com>, time@ice.com (Tim Endres) writes: >-> This is definitely wrong. I would be very suspicious of my register >-> settings. Here are mine (S58 and S111 are important): >-> . >-> . >-> S50=000 S51:254 S52:002 S54=000 S55=000 S56=017 S57=019 S58:000 S59=000 >-> . >-> . >-> S110:000 S111:030 S112=001 >-> . >-> . > >Is it really a good idea to turn off ALL flow control? I have my S58 set to >"002" for Full RTS/CTS flow control. If I can speed throughput without data >loss, please let me know. > Well, it doesn't really matter when running a uucp-g protocol, even with spoofing turned on, since the protocol itself will wait for protocol ACKs before sending more data, thus avoiding an overrun. You won't get any faster or slower if you turn hardware handshake on here. It DOES matter when running the modem for other protocols, such as streaming protocols (e.g. Zmodem). Then not having hardware handshaking on may cause data overruns, making the modem unusable for such protocols. You can see this often when using a Telebit hooked at 19200bps talking to a 2400bps modem and doing Zmodem. The 19200bps line can push data in much faster than it goes out, eventually overflowing the buffer since there is no protocol or hardware handshake to tell it to stop. The CTS light on the Telebit will turn off, begging the data to stop, but the SD light will stay on solid. In short, I recommend turning hardware handshake on with S58. It will not hurt uucp (and will not help), but it will help with non-uucp dial-in/dial-out connections. -- Gil. -- -------------------------------------------------------------------- -- Gil Tene "Some days it just doesn't pay -- -- devil@techunix.technion.ac.il to go to sleep in the morning." -- --------------------------------------------------------------------