Xref: utzoo comp.dcom.modems:7150 comp.unix.questions:26668
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rutgers!cbmvax!grr
From: grr@cbmvax.commodore.com (George Robbins)
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: <15566@cbmvax.commodore.com>
Date: 2 Nov 90 21:26:26 GMT
References: <1990Nov1.203225.14074@quagga.uucp>
Reply-To: grr@cbmvax.commodore.com (George Robbins)
Organization: Commodore, West Chester, PA
Lines: 44
To: m2xenix!quagga!ccfj

In article <1990Nov1.203225.14074@quagga.uucp> ccfj@quagga.uucp (F.F. Jacot Guillarmod) writes:
> I am getting about 500 cps transfer rate on a long distance (South Africa
> to U.S.) uucp dialup link.  Locally, I am using a Multi-Tech V.32 modem, 
> and the site in the U.S is using a Telebit T2500.  My dialler program 
> is a version hacked from the Hayes2400 dialler.
> 
> The local system is a 386 clone running SCO Xenix 2.3.2, and the uucico
> (which supports only 'g' protocol) has been modified to use a window
> size of 7 - this change increased throughput from about 220 cps to the
> present levels.  And, yes, I am driving my serial line to the modem at
> 19.2 kb!
> 

This may be a silly question, but do you have both ends fudged to request
the window size of 7?  It's not obvious, but each side requests window and
packet size and then the other side grants that or less.

>    possible?
> 
>    feed is batched/compressed, and I am using smail 3.1 to compress and
>    batch normal mail as well.
> c) if this performance is about what can be expected, can anybody give
>    an explanation of why faster transfer just doesn't happen?  Our
>    local PTT is willing to assist, but I need to know what to ask
>    them.

I don't know how much better you could expect, international dialup map
is still full of blank spaces and "here be dragons".  The 500 CPS is
similar to what I see between the US and Hong Kong using Telebit modems
in PEP mode.

I think you really need to spend some time analyzing why the thruput is
so slow.  If there is a lot of line noise or periodic events that make
characters dissapear, then I wouldn't expect much improvement.  If the
problem seems to be due to long propagation delay in one or both
directions then switching to a version of uucp which support one of
the "error free path" protocols might do wonders.  You also want to double
check to make sure the modems aren't running in 4800 BPS V.32 fallback mode
or periodically retraining.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)