Path: utzoo!attcan!uunet!wuarchive!usc!elroy.jpl.nasa.gov!lll-winken!sun-barr!rutgers!cbmvax!grr
From: grr@cbmvax.commodore.com (George Robbins)
Newsgroups: comp.dcom.modems
Subject: Re: Can we back up a sec?
Message-ID: <15363@cbmvax.commodore.com>
Date: 24 Oct 90 13:44:50 GMT
References: <1288.27204357@zswamp.fidonet.org>
Reply-To: grr@cbmvax.commodore.com (George Robbins)
Organization: Commodore, West Chester, PA
Lines: 47

In article <1288.27204357@zswamp.fidonet.org> root@zswamp.fidonet.org (Geoffrey Welsh) writes:
> 
>    I noted with interest Larry Snyder's question about UUCP throughput over 
> V.32 as compared to PEP, and am disappointed in the answers I've seen so far. 
> One person explained that the Telebit used spoofing... which I'm sure Larry 
> knows.
>  
>    The question at hand is whether the full-duplex nature of V.32 extends this 
> situation to 9600 bps. I know that the data packets need not be interrupted 
> to send ACKs, but even a 7-packet window would take less than half a second to 
> transmit at 9600 bps; it's entirely possible that the ACK packets might not 
> arrive before the pending window reaches its limit, causing the transmitter to 
> pause. This, of course, would prevent you from getting the maximum 
> theoretically possible throughput (1100-1200 CPS on V.32, using synchronous 
> framing a la MNP3 or V.42).
>  
>    Explicitly: Does anyone out there have throughput figures for UUCP 
> protocols between two well-tuned and reasonably lightly loaded machines over 
> a V.32 link?

I thought I covered this, but if you want some sample numbers, I have one 
connection that is currently V.32 when we call them and PEP when they call
us... (An interesting role reversal for a Telebit fan, but their Trailblazer
doesn't seem to answer the phone!)

Mode	Files	Characters	Seconds	C/Sec	B/S	Thruput (.55 compression)
PEP	21	5858185		4700	1246.4	12460	22.5 KB/S
V.32	59	14904357	19764	754.11	7540	13.5 KB/S

All data was compressed news batches, transfers of less than 100K were omitted to
mimimize skew due to overhead and poor timing resolution.  All data transfers
were in the same direction, from my system to the other system.

Note that these numbers aren't too surprising, the 7500 char/sec is about
what you'd get one a direct connect at 9600 baud, the uucp "g" protocol
simply doesn't drive the wire to 100% even under the best of conditions.

Increasing window size or packet size, or changing protocols would probably
help the V.32 get closer to 9600 BPS, but wouldn't do much for the the PEP
mode unless the protocol was adaptable to PEP packetizing charactersitics.
Protocol experiments are difficult and don't neccesarily help the average
guy with a binary license.

-- 
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)