jerry@oliveb.UUCP (Jerry Aguirre) (10/02/84)
There have been some articles posted lately about the advantages of
using 2400 baud modems for the distribution of news. Before someone
spends money to upgrade their modems consider that the same effect
could be had by improving the software involved.
I will ignore for the moment the news software and the relative
efficiencies of batching, compression, and "I have/send me"
distribution. Instead I want to examine the efficiencies of uucp
itself.
Uucp uses a fairly efficient protocol. It places the line in RAW mode
so that data can be sent without escapes. It buffers multiple packets
so that turn-around delays are eliminated. If I examine the uucp log
entries I see entries like 109 bytes per second of transmission. If a
1200 baud modem gives 120 bytes per second then the efficiency should
be 109/120=90%. This sounds pretty good.
But, it is still only using half the bandwidth available! Remember
that this is a full duplex modem. It really allows 1200 baud in EACH
direction so the real bandwidth is 1200 baud x 2 directions = 2400
baud! Bet you didn't know you already had 2400 baud modems.
However uucp does not make use of the full duplex capability. It
insists on sending files in one direction at a time. The only data
coming back are the packet acknowledgements which consume about 12%
of the available bandwidth. Just watch the send/receive lights on your
modem. The send light comes on solid but the receive light flickers on
and off (mostly off).
Presumably two backbone sites would have roughly equal amounts of news
to send to each other. If the sending and receiving could be
overlapped then the time consumed could be cut by almost half.
As uucp does protocol negotiation perhaps a new "full duplex" protocol
could be added as a preferred option. The advantage is that the
improvement could be made available to all sites instead of just those
that can afford expensive modems.
Jerry Aguirre
{hplabs|fortune|idi|ihnp4|ios|tolerant|allegra|tymix}!oliveb!jerryrpw3@redwood.UUCP (Rob Warnock) (10/03/84)
Jerry Aguirre makes a good point of how, by making uucp be full-duplex
(files moving in both directions at once), we could double the traffic
between backbone sites. But he uses this point to suggest we not rush
out to buy 2400-baud modems. Sorry, that's a non-sequitor.
If full-duplex makes it better, then full-duplex at 2400 baud makes
it even BETTER!
However, another possibility one might consider is to note (as Jerry did)
that uucp is essentially half-duplex, make it REALLY be so, and start
using the dial-up 9600-baud half-duplex modems that are now available
for about 1.5-2 times the 2400-baud prices. Do the arithmetic yourself.
(There are buffering/acknowledgement strategies that can make the modem
turn-around delay cause a negligible loss of throughput. Hint: batching
becomes even more important.)
Note: Some implementations of UNIX have difficulty receiving input
at 9600 baud, but other have shown that that can be fixed by careful
design of the tty drivers and careful attention to interrupt-off
times and latencies. (Unfortunately, it is often other non-tty
drivers, such as disks, which have long hunks of interrupt-off
code in them. It sometimes requires a logic analyzer to find the
actual offenders when you are losing input interrupts.)
Rob Warnock
UUCP: {ihnp4,ucbvax!amd}!fortune!redwood!rpw3
DDD: (415)369-7437
Envoy: rob.warnock/kingfisher
USPS: Suite 203, 4012 Farm Hill Blvd, Redwood City, CA 94061lepreau@utah-cs.UUCP (Jay Lepreau) (10/03/84)
The "Australian conterpart to uucp" (`AUS' I think) can use both directions of a full duplex channel, and is available for free. A paper describing it is in the Summer 1984 Usenix proceedings. Maybe some backbone sites could try running this. Jay Lepreau
lauren@vortex.UUCP (Lauren Weinstein) (10/03/84)
I've done some testing of my own regarding the merits of full-duplex UUCP communications, given the typical mail/news patterns we see and a variety of fairly complex technical factors. I did this when examining various ideas to improve efficiency in my own uucp implementations. I finally decided that the added complexity was considerably greater than any real gain in overall efficiency, and that other factors (including system load among other things) tended to swamp out any minor benefits. I decided to leave the protocol alone, other than to allow larger packet sizes under certain conditions (which is also of questionable real efficiency, but doesn't seem to hurt in most cases). Overall though, it seemed best to leave well enough alone. I have some detailed notes on this that I'll try to dig up and post to these groups. --Lauren--
ron@brl-tgr.ARPA (Ron Natalie <ron>) (10/03/84)
Can someone give me information on the fastest modems that I can run over dial up. Money is no object. Half duplex/Full duplex/ Async/Sync is no great problem. -Ron
jim@haring.UUCP (10/04/84)
Regarding bi-directional UUCP transfers: The traditional UUCP has two levels of protocol that are relevant here, the low packet level and the 'request/send' level, which constitutes the guts of uucico (in cntrl.c). The low packet level is easily selectable and this can already be done during the uucico startup handshake. Making the other protocol selectable is not so easy, and will also require changing the low level protocols, some of which assume that the program can only do one thing at a time. It could be done, but would be a major rewrite of the parts even HoneyDanBer couldn't refresh. If you can set up a line to have two multiplexed channels, then you can just run two traditional uucico's on it using different names at the two ends. I believe HoneyDanBer allows such name fiddling, but I could be wrong. X.25 is a better way to go than 2400 baud modems anyway. In fact, this exceedingly dull message is brought to you by the magic of a trans-Atlantic X.25 connection at one quarter the cost of an equivalent dial-up connection. Jim McKie Centrum voor Wiskunde en Informatica, Amsterdam mcvax!jim
smb@ulysses.UUCP (Steven Bellovin) (10/04/84)
Actually, there's a very serious inefficiency in many uucps. Because packets are being received in raw mode, the receiving process can be awakened on every *byte*, do a 1 or 2 byte read, then try to read some more. This sort of behavior can eat a machine alive! There have been several attempts to fix this (and System V uucps don't have the problem), but not all of them work well.
teus@haring.UUCP (10/06/84)
UUCP cannot and will not be full duplex (see the remarks of Jim for that). Also for many systems or links there is no need to. Of course full duplex will help but not that many as you think. Also doubling the speed will not say you are doubling the effective baud rate. The effective speed is depending on many other things. We did some extensive mesuring on "splendid quality" lines and came up that there is fi no diff in effectiveness for 4800 and 9600 lines. Sometimes even 300 baud for our trans atlantic links had a better effective speed as the 1200 baud links. So the quality of a line is a deal as well. About X.25: X.25 is cheaper if you already the equipment around, and can split the subscription costs over more links. As well you should run a protocol which is as simple (or cheap in overhead) as possible (f.i. f-protocol). F.i. if you use the g-protocol of UUCP and are o nly running it for one link during say 45 minutes per day, it is far more cheaper to do it via phone and normal modems. -- Teus Hagen teus@mcvax.UUCP (CWI, Amsterdam)