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>
steve@nuchat.UUCP (Steve Nuchia) (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? Probably not -- you're getting pretty close to theoretical. If your driver responds to flow control fast enough it won't cause a problem at low speeds. It is also possible that the T2000 is smarter about its buffer limits (or has larger buffers) than my TB+s and doesn't jiggle the flow control as much. I see a CTS toggle for every packet outgoing, and can measure a small difference in throughput. I have to support dial-in users, so the modems run with flow control on indial but my outdial scripts turn it off. The difference is not large enough to bother figuring out a way to turn it off on indial uucp, but it is measurable.
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
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
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
dave@imax.uucp (Dave Martindale) (04/12/90)
In article <1147@chinacat.Unicom.COM> chip@chinacat.Unicom.COM (Chip Rosenthal) writes: > >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. A useful note: if you have Telebit modems used for both interactive users and uucp, you may be able to just set flow control on and leave it that way. When you use uucp-spoofing mode, the flow control is handled by the packet protocol between uucico and the modem, and the setting of the modem's flow-control flag is irrelevant. So, you don't need to do anything special to turn off flow control for incoming or outgoing uucp connections. A possible exception to this is if you have non-PEP uucp connections. For those, no spoofing will be done, and you may have to turn off flow control. (or maybe not - uucico will only send 3 64-byte packets before waiting for an acknowledgement; the modem may not flow-control that small an amount of data).
root@nebulus.UUCP (Dennis S. Breckenridge) (04/13/90)
dave@imax.uucp (Dave Martindale) writes: >the modem's flow-control flag is irrelevant. So, you don't need to do >anything special to turn off flow control for incoming or outgoing uucp >connections. This may be true in some cases but if you run the modem locked at 19200 you ABSOLUTELY require flow control enabled. What happens is uucico will ship a packet of data to the modem and the modem/serial side is not ready, characters are dropped and the NAK is sent. This causes a retransmit, and so on and so on... I have also found that the modem, when using hardware flow control, will skid, (you 3B2 Eports guys know what this is!) and send a few more characters out the serial port when you drop RTS. If your ports card is true to nature it will lose it's mind, uucico will retransmit the packet... The overall effect is TB works fine at 9600 baud, but throughput decreases with 19200. The quick solution is to turn off all flow control, the modem has a large buffer and try you luck. It works on some sites namely Suns's, Consensys Powerports, AT&T IPC800's and Computone AT8's. I have not verified this on the new series TB+ or TB2500's -- ----------------------------------------------------------------------------- Dennis S. Breckenridge (604) 277-7413 dennis@nebulus.uucp VE7TCP EMACS: Eight Megabytes And Constantly Swapping! -----------------------------------------------------------------------------
dplatt@coherent.com (Dave Platt) (04/13/90)
In article <1990Apr12.002225.7496@imax.uucp> dave@imax.com (Dave Martindale) writes: > A possible exception to this is if you have non-PEP uucp connections. > For those, no spoofing will be done, and you may have to turn off flow > control. (or maybe not - uucico will only send 3 64-byte packets > before waiting for an acknowledgement; the modem may not flow-control > that small an amount of data). With the TrailBlazer Plus, you must turn off flow control if you have a non-spoofed UUCP connection and are running the modem-to-host connection at a higher speed than the modem-to-modem connection. The TB+ drops CTS quite quickly (its window is less than the 3-uucp-packet high-water mark) and ignores data which the host sends after that point. According to someone at Telebit with whom I spoke, the decision to drop CTS so quickly was a deliberate one... it ensures that interactive users can hit control-C (or whatever) and see the effect quickly when operating in this mode. Unfortunately, there's apparently no way to adjust the flow-control threshold (say, raise it to 256 bytes or so); it's either on, or off. -- Dave Platt VOICE: (415) 493-8805 UUCP: ...!{ames,apple,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
dave@imax.uucp (Dave Martindale) (04/14/90)
In article <1990Apr13.012803.1639@nebulus.UUCP> root@nebulus.UUCP (Dennis S. Breckenridge) writes: >dave@imax.uucp (Dave Martindale) writes: > >>the modem's flow-control flag is irrelevant. So, you don't need to do >>anything special to turn off flow control for incoming or outgoing uucp >>connections. > >This may be true in some cases but if you run the modem locked at >19200 you ABSOLUTELY require flow control enabled. What happens is >uucico will ship a packet of data to the modem and the modem/serial >side is not ready, characters are dropped and the NAK is sent. This >causes a retransmit, and so on and so on... My experience does not agree with this. I have driven a Trailblazer Plus that is about 3 years old now at 19200, and am now driving a T2500, at 19200 with no hardware flow control, and no problems. Remember that my comment applies only to PEP connections using protocol spoofing - it's not clear that you understood that, since you deleted the context of the remark.
michael@stb.info.com (Michael Gersten) (04/15/90)
In article <1990Apr12.002225.7496@imax.uucp> dave@imax.com (Dave Martindale) writes: > >A possible exception to this is if you have non-PEP uucp connections. >For those, no spoofing will be done, and you may have to turn off flow >control. (or maybe not - uucico will only send 3 64-byte packets >before waiting for an acknowledgement; the modem may not flow-control >that small an amount of data). Don't belive this in all cases--many sites have patched uucico to use 7 packets, and I think some unixes now come with 7 as the default. It only takes one patch with adb. (used to know where, but its been over a year since I patched it). -- Michael michael@stb.info.com denwa!stb!michael anes.ucla.edu!stb!michael Disclaimer: It works for me.