🚀 go-pugleaf

In article <800@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes:

[UUCP `g' protocol over satellite link]

>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.
>
>Has anyone analyzed this problem and come up with a bug fix.

You are correct about the eight-packets-in-flight limit in `g' protocol.

The right thing to do is write your own protocol module for uucico,
which better fits the link layer you're using.  There is precedent:

protocol	organization	link layer
--------	------------	----------
  t		CSS (seismo)	TCP/IP
  f		CWI (mcvax)	X.25 (standard with PAD)
  x		AT&T		X.25 with VPM

You say that your satellite connection is error corrected; is it also
flow controlled? If so, the `t' protocol is probably what you want.
It's a waste to run `g' protocol over an error corrected link anyway
because the effort that `g' puts into checksumming is wasted.

	Erik E. Fair	styx!fair	fair@lll-tis-b.arpa

In article <800@oliveb.UUCP> jerry@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

Standardly uucp only has a window of 3 and a packet size  of 64  bytes
(it is compiled in under most versions).  I've tried transfering stuff
over networks which seem to match your description  and found the best
thing to do is to allow the window and packet size  to be specified in
the L.sys  file for each connection.  Unfortunetly  the remote machine
must also be told about any changes  in window/packet sizes before the
g-protocol is invoked.  So if you wanted to do this  you would have to
upgrade both ends.

You can then increase the ammount of data you are prepared  to send in
advance of an acknowledgement and so increase your throughput.

These fixes are built into UKUUCP (the UK standard uucp).

Okay let's hear the Honey DanBer crowd beat that :-)
-- 
--
UKUUCP SUPPORT  Lee McLoughlin
	"What you once thought was only a nightmare is now a reality!"

Janet: lmcl@uk.ac.ukc, lmjm@uk.ac.ic.doc
DARPA: lmjm%uk.ac.doc.ic@ucl-cs
Uucp:  lmjm@icdoc.UUCP, ukc!icdoc!lmjm

lmjm@icdoc.UUCP says that UKUUCP is hacked to allow one to specify the
window and packet size in L.sys for each connection.  It would be more
interesting, though of course much harder, to have UUCP experiment
during each call to find optimal values for these parameters.  This
would take a new protocol, I guess.

The approach of having UUCP experiment is preferable, first, because it
requires less human parameterization; and second, because it adjusts
better to fluctuating conditions.  For instance, the window and packet
size should go up when there are satellite delays on the line, but they
should go down when there is noise on the line that causes garbling.
U.S.  transcontinental calls vary from call to call both in the
presence/absence of satellite delays (actually, this may only vary
between long-distance companies, not between calls using the same
company) and in the amount of noise.  So it would be nice to have UUCP
compensate dynamically.

Of course, there are other types of connections that favor
different window and packet sizes, with or without automatic
experimentation.  There are half-duplex 9600 baud modems, I have read,
that transmit without errors and simulate full duplex by frequent
handshaking.  There can sometimes be delays of a few seconds in the
transition between send and receive, though.  It seems like a very large
window and packet sizes would make UUCP work quite well with this sort
of modem, so that it could pay for itself if bought for sites that
exchange lots of data long-distance.  Large packet sizes are of course
appropriate for any transmission medium that does its own
error-checking.

Finally, a couple of notes.  (1) Even though it looks like (when you
watch the send/receive lights) that the packet size should be larger,
4.3 UUCP here gets 210 to 220 cps using a Hayes Smartmodem 2400.  Pretty
good.  (2) I'm not actually sure what "window size" is.  If I look like
a total fool in mentioning it above, please forgive me.

----
Sam Kendall			{ ihnp4 | seismo!cmcl2 }!delftcc!sam
Delft Consulting Corp.		ARPA: delftcc!sam@NYU.ARPA