[comp.unix.xenix] Error-correcting modems & uucp

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>

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