paul@frcs.UUCP (Paul Nash) (04/06/90)
I am about to get a Telebit T2500, and have a few questions about this fairly complex beastie. Obviously, the T2500 has uucp spoofing if connected to another PEP modem, and will run its own error correction between modems. The SCO- supplied dialTBIT (I use Xenix, for my sins) runs the link between modem and computer at 19200 bps, with hardware flow control. However, when I use the Telebit with non-PEP modems (v22bis, say) should I lock the interface at 19200 and use hardware flow control for the speed conversion, or should I let the port change speeds down to 2400 bps or whatever? In addition, I have a pair of v22bis MNP4-compatible modems. At present I run them as dumb modems (AT&E0), and would like to know whether there are advantages or disadvantages to using MNP on top of (under?) uucp. Should I lock the interface at 9600 and use RTS/CTS flow control, or is it better to leave the modem as I have at present, and ignore the fact that it has MNP? Obviously, for normal tty-type work, it is better to use MNP (if the remote supports it) in an attempt to defeat line noise. Just what is the optimal setup for this, and for the modem when left for dial-in work? Any experiences greatfully received. Either post to the net if you think that there is sufficient interest (I think that it is, which is why I am posting :-), or e-mail me and I will summarise. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ...!uunet!ddsw1!proxima!frcs!paul paul@frcs.UUCP -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
steve@nuchat.UUCP (Steve Nuchia) (04/07/90)
In article <963@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes: >However, when I use the Telebit with non-PEP modems (v22bis, say) >should I lock the interface at 19200 and use hardware flow control for >the speed conversion, or should I let the port change speeds down to >2400 bps or whatever? Run with the speed locked at 19200 and NO flow control, unless it gives you problems with specific neighbors. The uucp protocol has a limited send-ahead window, and there is enough memory in the modem to buffer it. But the modem doesn't know that, and will jiggle with the flow control if it is enabled, slowing the whole process down noticably. The (one?) problem that comes up when doing this is that there is a feature in the modem protocol specs that says they can drop the stop bit from every eight byte when the interface is running faster than the analog link. I believe that the spec should enable this only when *both* digital links are fast, but telebit does it all the time. Most 2400 and even 1200 bps modems can receive this properly, but some can't. If you have a neighbor who can't cope with it, it will show up as abysmal throughput or connections timing out, and you will have to arrange to run your digital link at the connection speed when talking to that site. >In addition, I have a pair of v22bis MNP4-compatible modems. At present >I run them as dumb modems (AT&E0), and would like to know whether there >are advantages or disadvantages to using MNP on top of (under?) uucp. It depends on the quality of the line and the kind of traffic. MNP error correction slows down the link slightly, but takes less time to deal with a bad error than the timeouts in uucico do, so on a lousy line it might be a win. MNP compression is a win only if you are sending uncompressed files; if you precompress your traffic it is best to run the modems without compression. >Should I lock the interface at 9600 and use RTS/CTS flow control, or is ... >Just what is the optimal setup for this, and for the modem when left >for dial-in work? Depends on how hard it is to reconfigure for uucp. I'd make it as easy to use for humans as possible, then make uucp cope with it as best it can. That is an administrative, not a technical, opinion.
larry@nstar.UUCP (Larry Snyder) (04/08/90)
> However, when I use the Telebit with non-PEP modems (v22bis, say) > should I lock the interface at 19200 and use hardware flow control for > the speed conversion, or should I let the port change speeds down to > 2400 bps or whatever? That is what we do on nstar. With the port locked at 19200 and proper flow control (hardware only) is is possible to get increased throughput on MNP connections (like 280 cps using 2400 baud modems) and the remote users will not have to use the control-D to find a correct gettydefs entry.
larry@nstar.UUCP (Larry Snyder) (04/08/90)
In article <21466@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes: > > Run with the speed locked at 19200 and NO flow control, unless it > gives you problems with specific neighbors. The uucp protocol In my case, I need flow control since the machine is used for other protocols besides UUCP (ie: zmodem, ymodem, sealink and various others). If someone only uses uucp - no flow control might work for them - but these other protocols require flow control - or let the modem "float" to the connect rate. -- ...!iuvax!ndmath!nstar!larry -or- larry@nstar
andrew@ramona.Cary.NC.US (Andrew Ernest) (04/08/90)
In article <21466@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: >in the modem to buffer it. But the modem doesn't know that, >and will jiggle with the flow control if it is enabled, slowing >the whole process down noticably. Hmmm. I've been using full duplex RTS/CTS flow control ever since I installed Jim Murray's async driver and locked the interface speed on my T2000. 2400 bps uucp callers get 222 - 227 cps. Would it be much better without flow control? I agree about MNP...use only if necessary. May I add something unrelated which might come in handy for folks trying to get 2400 bps modems to talk to Telebits? Some 2400 bps modems may experience lots of connect failures trying to call a Telebit modem if the 2400 bps modem is set to detect a busy signal. On some modems this is the default setting. On my old (pre-MNP) EVEREX this sort of thing is controlled with ATX? where '?' is a single digit. X4 fails all the time. X2 works great. Note that I've redirected followups to this article to comp.dcom.modems. -- Andrew Ernest <andrew@ramona.Cary.NC.US>
karl@ddsw1.MCS.COM (Karl Denninger) (04/08/90)
In article <511445@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >In article <21466@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes: >> >> Run with the speed locked at 19200 and NO flow control, unless it >> gives you problems with specific neighbors. The uucp protocol > >In my case, I need flow control since the machine is used for other >protocols besides UUCP (ie: zmodem, ymodem, sealink and various >others). If someone only uses uucp - no flow control >might work for them - but these other protocols require flow control - >or let the modem "float" to the connect rate. Strange; we run our Telebit locked at 19200, with XON/XOFF flow control enabled. When uucp startup occurs, the Telebit appears to automaticlly switch off flow control for the session (during spoofing). I know that uucp does in the device flags, since that can be easily inspected. This allows lowspeed logins on the Telebit without trouble, and high speed uucp connections. It all works. We >can't< run hardware flow control, since we have an Equinox board, which doesn't support both it and modem control on the same port. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
larry@nstar.UUCP (Larry Snyder) (04/09/90)
In article <816@ramona.Cary.NC.US>, andrew@ramona.Cary.NC.US (Andrew Ernest) writes: > Hmmm. I've been using full duplex RTS/CTS flow control ever since I > installed Jim Murray's async driver and locked the interface speed on > my T2000. 2400 bps uucp callers get 222 - 227 cps. Would it be much > better without flow control? > > I agree about MNP...use only if necessary. Why not use MNP all the time? With the modem locked at 19200 to the machine - even 2400 baud callers with MNP get transfers in the 280cps range if their modem is also locked at a higher baud rate. I would assume if you kept your blazer locked at a fixed DTE speed - slower speed MNP callers would also get a throughput greater than the connect speed. -- ...!iuvax!ndmath!nstar!larry -or- larry@nstar
chip@chinacat.Unicom.COM (Chip Rosenthal) (04/09/90)
karl@mcs.MCS.COM (Karl Denninger) writes: >Strange; we run our Telebit locked at 19200, with XON/XOFF flow control >enabled. Be careful there. This works fine when calling out with uucp spoofing 'cause the spoofing code disables it. This also works fine for interactive use. But, this will blow you out of the water when you try to uucp to a site which runs slow modems. The first character flowing through which looks like an XOFF will lock up the modem. This one bit me just two weeks back when I brought up telebits on chinacat. -- Chip Rosenthal | You're not some icon carved out chip@chinacat.Unicom.COM | of soap, sent here to clean up Unicom Systems Development, 512-482-8260 | my reputation. -John Hiatt
steve@nuchat.UUCP (Steve Nuchia) (04/09/90)
In article <511454@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >Why not use MNP all the time? With the modem locked at 19200 to the >machine - even 2400 baud callers with MNP get transfers in the 280cps Because, for file transfer (like, say, oh maybe news batches?) compress works better than MNP compression. Leaving the MNP compression enabled for compressed files loses big time. MNP error correction is another question. I haven't seen any numbers, but if the speed penalty is less than a percent or maybe two it would be a win on very noisy lines. These comments apply to uucp. The whole thread applied to uucp. Just look at the Subject: line. Interactive users need all the help they can get. -- Steve Nuchia South Coast Computing Services (713) 964-2462 "The study of the art of motorcycle maintenance is really a miniature study of the art of rationality itself. Working on a motorcycle, working well, caring, is to become part of a process, to achieve an inner peace of mind. The motorcycle is primarily a mental phenomenon." -- Robert M. Pirsig
karl@ddsw1.MCS.COM (Karl Denninger) (04/09/90)
In article <1138@chinacat.Unicom.COM> chip@chinacat.Unicom.COM (Chip Rosenthal) writes: >karl@mcs.MCS.COM (Karl Denninger) writes: >>Strange; we run our Telebit locked at 19200, with XON/XOFF flow control >>enabled. > >Be careful there. This works fine when calling out with uucp spoofing >'cause the spoofing code disables it. This also works fine for interactive >use. But, this will blow you out of the water when you try to uucp to a >site which runs slow modems. The first character flowing through which >looks like an XOFF will lock up the modem. This one bit me just two >weeks back when I brought up telebits on chinacat. Solution? Don't do that, or dial out only to that site and have the dialer script turn off XON/XOFF (you DO have DTR-resets-to-defaults, do you not?). This is only a problem if Telebits are your only modems and you have to allow uucp dialin from a slow modem. The problem with the Equinox boards isn't that they wouldn't like to support hardware flow control, it's that they couldn't get 24 ports worth of flow control signals + modem control + data lines out the back of the board! -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
paul@frcs.UUCP (Paul Nash) (04/11/90)
In article <963@frcs.UUCP>, paul@frcs.UUCP (Paul Nash) (ME) writes: > I have a pair of v22bis MNP4-compatible modems ... > ... advantages or disadvantages to using MNP on top of (under?) uucp. > Should I lock the interface at 9600 and use RTS/CTS flow control ... I have conducted a few (_very_ few) tests, with no line-condition checking, so don't take these results as accurate, but: file xfer (uucp-g) 7168 bytes (average of about 5 each type & each way): dte interface 2400 bps, no mnp (v22bis): 214 cps dte interface 2400 bps, MNP4 (v22bis): 214 cps dte interface 9600 bps, MNP4 (v22bis): 148 cps From this I _assume_ that MNP4 doesn't hurt (the modems don't do MNP5++). It also seems that a fast dte speed on a slow (and cheap) modem (Octocomm osi8224a) can only hurt! This is slightly at odds with some of the network users' experience, so maybe I'm doing something wrong (like using Xenix?). > Any experiences greatfully received. Either post to the net if you > think that there is sufficient interest (I think that it is, which is > why I am posting :-), or e-mail me and I will summarise. To those who have responded so far (both net & mail), many thanks. I _will_ summarise, but also want to do some tests to include with the summary, and I am being delayed 'cos the T2500 is still clearing customs (they promised it out yesterday, so ...). However, I _will_ summarise (promise!). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ...!uunet!ddsw1!proxima!frcs!paul paul@frcs.UUCP -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
chip@chinacat.Unicom.COM (Chip Rosenthal) (04/11/90)
In article <967@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes: > dte interface 2400 bps, MNP4 (v22bis): 214 cps > dte interface 9600 bps, MNP4 (v22bis): 148 cps What you are probably seeing is the overhead of (a possibly poorly implemented) flow control. Some of the recent messages in these groups have been dancing around a point, but I'm not sure anybody has flat out said it: For uucico you do not want flow control; for interactive users you do want flow control. If you want to do both, then you have to make a compromise: throughput vs dropped chars. If you want to test the flow control theory, you could split out the transmitting vs receiving stats. I would expect that the receive times would be close, and it's mostly transmit where you are seeing the hit. -- Chip Rosenthal | You're not some icon carved out chip@chinacat.Unicom.COM | of soap, sent here to clean up Unicom Systems Development, 512-482-8260 | my reputation. -John Hiatt
garyb@crpmks.UUCP (Gary Blumenstein) (04/13/90)
In article <1990Apr9.125628.4431@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >[stuff about configuring Telebits deleted..] > >The problem with the Equinox boards isn't that they wouldn't like to support >hardware flow control, it's that they couldn't get 24 ports worth of flow >control signals + modem control + data lines out the back of the board! Karl, If I'm not mistaken, I beleive the next Equinox drivers will let you borrow additional signals from ANY port. Hence you will be able to get both harware flow control with modem control on the same line. Don't ask me how on earth they did this but its going to make for some interesting cabling! :-) -gb -- Gary M. Blumenstein, UNIX Network Administrator // CIBA-GEIGY Corporation USA ----------------------------------------------------------------------------- Phone (914) 347-4700 7 Skyline Drive, Hawthorne, NY 10532 FAX (914) 347-5687 UUCP ...uunet!philabs!crpmks!garyb