jerry@oliveb.UUCP (Jerry Aguirre) (04/21/86)
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.
Has anyone analyzed this problem and come up with a bug fix.
Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|glacier|olhqma}!oliveb!jerryfair@styx.UUCP (Erik E. Fair) (04/23/86)
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
clewis%mnetor@mnetor.UUCP (04/24/86)
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
lmjm@ivax (04/29/86)
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
angela@pc.ecn.purdue.edu.UUCP (Angela Kelly) (08/28/86)
just a little test, sorry!