Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!ucsd!nosc!crash!simpact!jeh
From: jeh@dcs.simpact.com
Newsgroups: comp.mail.uucp
Subject: Re: How efficient/fast is uucp?
Message-ID: <1556.26d282ea@dcs.simpact.com>
Date: 22 Aug 90 20:04:42 GMT
References: <8464@pitt.UUCP>
Organization: Simpact Associates, San Diego CA
Lines: 57

In article <8464@pitt.UUCP>, jonathan@cs.pitt.edu (Jonathan Eunice) writes:
> How efficient is/are the protocol(s) used by uucp?  How do they compare
> with zmodem?  For some reason (not based on anything resembling
> knowledge), I have the impression that uucp uses crufty, old, slow
> protocol(s).  Am I in left field?  

Yes, you're in left field.  

The worldwide de facto standard for uucp dialup with 'g' protocol uses packets
with 64-byte data fields and six-byte headers, thus achieving about 90%
utilization of the available bandwidth.  Many modern uucps can be configured to
support larger packets, up to 4096 bytes, which squeezes the "overhead" down to
almost nothing, but at the expense of MUCH greater retransmission cost when
errors occur.  Some sites with reliable connections run with 1K packets, which
seems to be a good compromise.  

> In a related matter, how difficult would it be to replace uucp's
> protocol(s) with zmodem or a similar fast protocol?  Or with a slower
> one (!), or a compressed one, or whatever?  Ie, is uucp bound to its
> current protocol(s)?

There are at least three sides to the "how difficult" question.  

Technically:  There is a "protocol negotiation" sequence in the uucp startup, 
so it is possible to have a uucico that supports both the standard 'g'
protocol and, say, zmodem, and which will use the appropriate protocol for
each host to which it connects.  

Legally:  I think there are some copyright/licensing issues around the Zmodem
protocol.  

Practically:  There are tens of thousands (at least) of uucp sites out there.  
The chances of getting a significant number of them to use a new uucico just
because it supports zmodem are slim to none.  

Now, if you came up with a "magic bullet" that offered double or triple the
performance of current uucps, that would be another matter.  But don't think
"compression", because news batches (which are the bulk of the traffic) are
already compressed, so further compression will hurt rather than help. 

One of zmodem's features, the ability to restart an interrupted file transfer
from where it left off rather than having to start all over again, is really
nifty for the PC user who is downloading tens of megabytes from BBSs at 2400
bps, but would be of limited use for most uucp traffic.  At my site and the
other sites I've looked at, at least, the great bulk of uucp traffic consists
of news batches which are already compressed and which are already broken up
into files of about 50 Kbytes each.  These are moved via uucp through
Trailblazer modems at 1200 to 1400 char/sec; thus the typical large file we
deal with only takes 30 to 40 seconds to transfer.  If the call dies before
completion, on the next call we restart with that same file.  It just isn't
worth the hassle of putting up a new protocol to save less than a minute on the
occasional interrupted call. 

	--- Jamie Hanrahan, Simpact Associates, San Diego CA
Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG 
Internet:  jeh@dcs.simpact.com, or if that fails, jeh@crash.cts.com
Uucp:  ...{crash,scubed,decwrl}!simpact!jeh