Satellite delays slow UUCP

Erik E. Fair fair at styx.UUCP
Wed Apr 23 14:15:23 AEST 1986


In article <800 at oliveb.UUCP> jerry at 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 at lll-tis-b.arpa



More information about the Comp.unix.wizards mailing list