Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!usc!rutgers!mcdchg!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.uucp
Subject: Re: How efficient/fast is uucp?
Message-ID: <1990Aug24.152938.7413@chinet.chi.il.us>
Date: 24 Aug 90 15:29:38 GMT
References: <8464@pitt.UUCP> <1556.26d282ea@dcs.simpact.com>
Organization: Chinet - Chicago Public Access UNIX
Lines: 67

In article <1556.26d282ea@dcs.simpact.com> jeh@dcs.simpact.com writes:
>In article <8464@pitt.UUCP>, jonathan@cs.pitt.edu (Jonathan Eunice) writes:
>> 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.

This is true for direct connections with "real" full duplex modems where the
turn-around time for the ack packets is insignificant.  However, many
connections currently happen over packet-switched networks, satellite links,
and/or modems that pretend to be full duplex but actually take some time
to switch directions.  Then you can end up waiting for the ack's and
reducing throughput.  On a network where there is a per-packet fee, the
ack's and the fact that you often send unfilled network packets can be
expensive.  Older g's allow a 3-packet window that can be sent
before the ack's get back, newer ones allow 7 which is the limit for
the g protocol field that specifies the number.  Some real-world figures
for satellite xfers (from todays xferstats on another machine) show
about 120 cps over a 2400 baud connection to a machine with the 7-packet
window, 90 cps to a machine with a window of 3.  Obviously there is some
room for improvement here.  On top of this, there is the non-windowed
per-file handshake and the fact that mail messages carry along a second
small file for the uuxqt command. Increasing the packet size or window
wouldn't help much with mail transfers, since the files often don't
fill the existing window.  Note: this applies to trailblazers as well,
although you have to look at real connect time to see it - the xferstats
don't count the per-file handshake time.

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

The big hangup here is that you need a source license to begin with, and
then you can't distribute copies.  Does anyone have a HDB compatible
uucico that can be freely distributed? 

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

The only ones that matter are the ones that cost you money for your
connections.

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

My figures show that it would be possible to double the speed of the
7-window version and almost triple the 3-window version when using a
satellite link.  Eliminating the acks (except per-file) could cut the
cost in half if you pay per network packet.

I'd like to see a protocol where you could specify a minimum and
maximum packet and window size per host, device and dialer.  The
highest maximum for the connection would then be used a starting
point for negotiation with the remote, and then the sizes would
dynamically adjust downward in response to errors with appropriate
logging so the setup could be changed if needed.  Also, file
boundaries should stream through the window.

Les Mikesell
  les@chinet.chi.il.us