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