Satellite delays slow UUCP

[Chris Lewis]

In article <800 at oliveb.UUCP> jerry at oliveb.UUCP (Jerry Aguirre) writes:
>I have noticed a problem while running UUCP thru a circuit that includes
>a satellite delay.  Even though the channel is configured for 2400 baud
>the thru-put slows to under 500 baud.
>
>When I monitor the link I notice that the sender will send a burst of
>data, the line will be idle for approximately 1 second, the receiver will
>send a short burst of data (presumably one or more acks), and then the
>sender will immediately send another burst of data.
>
>The lines are clean (error corrected) and the round trip delay is
>approximately 1 second.  The UUCP is what came with 4.2BSD.
>
>The UUCP 'g' protocol seems configured around the magic number of 8
>packets of (I think) 64 bytes each.  That should be enough to keep the
>line busy until the ack for the first packet is received.

We were grunging around in the "g" protocol and seem to have discovered
that, yes UUCP does use a 8 slot circular list of packets, but it is
using a 3 packet window - it can send up to 3 packets before requiring
an acknowledge.  Hence, you can send up to 3 packets before having
to wait for the acknowledge.  

Further, I believe BSD uucp's use "select" with timers to do 
their reads - the receiver goes back into a "select" to read the packet, 
and only if the select times out does it actually send an acknowledge for
a packet it has already received.  However, the transmitter stalls
if it has sent 3 packets out - so in your case (if the transmitter can keep
up to the receiver), you have to wait the full round-trip time after
the last packet in a window before the receiver times out and sends the
acknowledge.

Simple arithmetic would show that sending 3 packets at 2400 baud takes roughly 
1960/2400 seconds (.80 sec., say - this is assuming each character is 10
bits (8 data, one start, one stop), and ignoring packet header overhead), and 
then you have to wait for the 1 sec. round trip (plus some overhead on 
the other end of course) -> approx 2 seconds to send 3 packets and get an
acknowledge.  That's only a .8/2 duty cycle.  Effectively something like 
960 baud.  Not factored in is the window timeout etc.  Not good for your 
situation.  You could always try changing the "WINDOWS" define in pk.h to 
something more than 3 (but <= 8!) in the transmitting uucp, but I make no 
guarantees that it'll work, nor that it'll be compatible with systems that 
haven't been zapped in this way.

Another possibility, you could always defeat the "select" and insist on
sending acknowledges on all packets asynchronously with the transmitter, 
then you'd have a string of acknowledges spaced out going back over the 
line to the transmitter.  That might help.  Or not....

Note: my comments are from scanning BSD 4.3 UUCP sources.  Some of
the details may be different in 4.2 source.

BTW: we appear to have found a problem with 4.3 "g" protocol in this area, 
but the kludge we've inserted is "tripping" more often than I believe 
it should be.  When I finally get a "good" solution to it, I'll post 
details (it's a trivial change to pk0.c).  Unless Rick Adams (who has 
gotten details by mail) tells me we're all wet (eg: it should be fixed 
somehow else, or we've got an old copy...).  If we're not all wet, it 
appears that UUCP over a line with such a delay would never work with 4.3 UUCP.

All this time I was hoping I'd never have to dive that far in to UUCP.
Sigh...
-- 
Chris Lewis,
UUCP: {allegra, linus, ihnp4}!utzoo!mnetor!clewis
BELL: (416)-475-8980 ext. 321