Xref: utzoo comp.dcom.modems:7194 comp.unix.questions:26726
Path: utzoo!attcan!uunet!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!ucsd!nosc!crash!nusdecs!rwhite
From: rwhite@nusdecs.uucp (0257014-Robert White(140))
Newsgroups: comp.dcom.modems,comp.unix.questions
Subject: Re: uucp throughput on international link using Multi-Tech V.32
Keywords: speed speed speed
Message-ID: <1990Nov5.235125.20448@nusdecs.uucp>
Date: 5 Nov 90 23:51:25 GMT
References: <1990Nov1.203225.14074@quagga.uucp>
Organization: National University San Diego
Lines: 110

In article <1990Nov1.203225.14074@quagga.uucp> ccfj@quagga.uucp (F.F. Jacot Guillarmod) writes:
>a) is 500 cps over such a link expected, or is better throughput  
>   possible?

Better V.32 performance is, indeed possible.  The lag you indicate is
a little large to be induced by the real transmittion delays induced
by things like satalite travel time and such.  "Local"
V.32/V.42/V.42bis calls I make always have more-than 9600baud
performance barring alarms from garbeled info.  (I have a
sometimes-unreliable communications board in my host).

>b) if better performance is possible, how can it be attained?  My news
>   feed is batched/compressed, and I am using smail 3.1 to compress and
>   batch normal mail as well.

>e) if you could start from scratch, what modems would you use to
>   maximize the speed of such a link?  Would V.42 make any difference, 
>   given that the files to be transferred are already compressed?
>   The reasoning behind this question is that an improvement in the
>   performance translates into hard cash, and could write off the
>   cost of new hardware in a few months.

Many yesses here (to follow)!

First the V.32, V.42, and V.42bis info...

V.32 is basically a "standard" modulation technique w/answer protocol
recommendations.  One of the bizzare things about it, however, is that
it dosn't spesify the "inital connect data rate" in the V.32 specs.
Some modems will initally connect at 9600bps and others will start at
2400bps.  In both cases the modems are V.32 compliant.  The fast-start
modems fall-back and the slow-start modems fall-forward durring
protocol initiation.  If you mix-and-match these techniques you may
end up running at 4800bps on a line that could easily do full 9600bps
work.  If you are having this problem you should:
	a) see if you can man-handle the slow-start modem into
fast-start mode.
	b) See if you can restrict the connection to higher speeds
only.
	c) lengthen the fallback time on the fast-start modem and
shorten the fall-forward time on the slow-start modem.

V.42 and V.42.bis summary;  if your modem does not have BOTH get it
upgraded or turn it in on a real(tm) modem.

V.42 is the ARQ (automatic retransmit request) and protocol
negotiation standard.  It is equavilant to mnp1-4 for all purposes.
It does not do any data compression but it does let the modems argue
about life after the connection is established, without disturbing the
data flow.  I beleive (read "disclaimer") that without the V.42 the
lines will retrain down to lower speeds when disruptive line noise
occurs but the retrain up is much rarer.  That as may be, without V.42
the software protocol has the full responsibility for error control;
since the modem(s) becomes a dedicated processor for error control the
V.42 can usually correct minor problems faster and more effeciently
than the software protocols.

V.42bis is the data compression technique.  This technique is/was more
commonly known as "LAPM" and is substancially different than mnp5.
mnp5 data compression will *reduce* the throughput on already
compressed or truely random data.  This is because bandwidth is used
to transmit and reinitalize the mnp5 data dictionary.  V.42/LAPM does
not have this problem so it is OK to use on already compressed files.
As an added bonus, V.42/V.42bis will not send the
automatic-noise-burst durring connect attempts to non V.42/V.42bis
modems.  Simplifying most dilaing/login scripts in various
environemnts.

Remember that V.32, V.42, and V.42bis are all independant of
ehachother as standards (tho 42bis ?may? require 42 don't actually
know on that score) and the combination of all three are your
best-bet.

What I would (and indeed did) do:

I have USRobotics V.32 modems on my host machines.  Their support is
good and modem bios upgrades and warentee service/support are free for
a year (or more, I don't remember).  I would have opted for the dual
standard modems (both V.32 and a propriatary "HST" protocol upgrades
from either available).

I have a dual standard at home (I use the HST stuff for other uses but
have never been able to test uucp using that protocal) and consider it
a good deal in general.

I have set the modems to use V.42bis at all times and to answer calls
using CCITT answering tones.  (the dual stnadard will auto-switch from
CCITT to HST but not the other way around).  A couple of hours of
setup experimentation has gotten me a good number of optimal
(modem-spesific) settings both in the hardware and in my uucp files.

I am quite satisfied with this setup.

Would it be worth it for you to change?  Probably not.  Under bad
conditions I have gotton as low as 700cps on local calls.  I happen to
beleive that this has been caused by the modem being able to go to
fast for the host port and then having to wait around for a uucp alarm
to restart/continue transmission.

You may be able to up your transmission rate by 1) getting V42/V42bis.
2) watching the modem to see if you have several-second dead spotts
durring transmission (indicating a flow control problem or some such).
and 3) tweaking the ARQ or uucp packet sizes DOWN where possible while
increasing the window size in whatever protocols you use.

Don't know how much help I have been...

Enjoy.

Rob.