Xref: utzoo comp.unix.sysv386:9170 comp.dcom.modems:10496 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!malgudi!ucunix.san.uc.edu!tut.cis.ohio-state.edu!VAX1.CC.UAKRON.EDU!neoucom.edu!wtm From: wtm@uhura.neoucom.EDU (Bill Mayhew) Newsgroups: comp.unix.sysv386,comp.dcom.modems Subject: Re: Getty for ISC/Telebit T-2500 w/autobaud via the CONNECT msg? Keywords: Telebit, getty, autobaud, bi-directional Message-ID: <1991Jun20.143444.12531@uhura.neoucom.EDU> Date: 20 Jun 91 14:34:44 GMT References: <1991Jun15.030807.28565@pegasus.com> <1991Jun15.154304.25987@uunet.uu.net> Organization: Northeastern Ohio Universities College of Medicine Lines: 61 << whether or not to lock the interface speed of Telebit modem >> Locking the interface speed is pretty handy. I typically run my port getty at 19200 and let the modem, in my case a Trailblazer +, handle the speed translation. There are some things you have to watch out for. Namely with speed translation going on in the modem, there is inevitable need for flow control. In normal dial-up the default xon/xoff flow control works quite well. However, the flow control will zap uucp connections by adding extra characters to the data stream. At 1200 and 2400 bps, the modem will insert flow control often enough that the window of 3 packets is sure to get zapped with the result being a deadlock of infinite retries. The easy way to get around the flow control problem is for your site to dail out to outher sites with the modem set at a speed appropriate to the connection type. You could still get flow problems if you are running the interface at 4800 bps with the assumption of getting an MNP-4 2400 bps connection. In such cases, I disable MNP compression (limit to level 3). The Trailblzer, and most v.32 modems, have the ability to use the RTS/CTS leads for flow control. This has the advantage of keeping the flow out of the character data stream. Also advantageous is the fact that the flow control latency is reduced because the flow message is not queued in input buffers, etc; it can go straight to the driver. I believe the stock ISC/ATT asy port driver does not have RTS/CTS flow capabilities; I don't recall off hand, but the fas port driver available at your friendly ftp connection may have it. Auto bauding getty certainly is possible, though I have not seen it available for for ISC. I am using a TB+ on our HP-9000 with HP's uugetty. Their uugetty looks for carriage returns initially to set the speed. It usually one takes one return to recognize 9600 or 19200 but may take up to 5 to recognize 1200 bps. Obviously, here I let the modem match the speed of the connection; no problems with flow control. No need to read the CONNECT message from the modem, vi even gets the right window size. In this case, I use Q3 for the verbosity setting (no messages, ever). I've tried the Q6 and have occasionally had troubles with the modem getting confused about what modality it is in, resulting getting getty babble. I use the fist entry in the dialer chat script to switch back to Q0 to allow progress monitoring. There is one last thing. I've heard some complaints about people that use TB modems with locked interface speeds of a phenomenon called bit-shaving. Apparently TB modems might have slight speed mismatches when doing speed translation. From my understanding, newer modems aren't bothered, but older modems have problems staying in sync. I've also been told that the newer firmware for TB modems mitigates the bit-shaving problem. Hope this is of some help, Bill -- Bill Mayhew NEOUCOM Computer Services Department Rootstown, OH 44272-9995 USA phone: 216-325-2511 wtm@uhura.neoucom.edu ....!uunet!aablue!neoucom!wtm via internet: (140.220.001.001)