How to speed up UUCP?

[Guy Harris]

> First the obvious.  Ensure that your system AND THE UTTER (sic) system
> can pump characters this fast.  Many systems cannot pump bytes at more
> than 4800 baud (480 chars/sec).

More importantly, ensure that both systems can *receive* characters this fast.
It's a lot easier to send them at 9600 baud than to receive them at that rate
in most systems.

> At high baud rates (and expecially over ethernet and the like) this will
> kill performance.

Some, anyway.  At 19200 baud, I've seen 1742 characters per second, based on
the values reported in SYSLOG, and at 38400 baud I've seen 3435 characters per
second.  The "g" protocol may noticeably cut performance, but it certainly
doesn't kill it.  It appears to cause about a 10-15% hit here.

> Hack your own protocol that sends out much larger packets.

If you're doing it over Ethernet or Datakit, please don't hack your own
protocol; run atop some reliable flow-controlled protocol such as TCP/IP or
whatever Datakit provides in that arena, and either use the "t" protocol from
4.3BSD's UUCP or the "e" protocol from Honey Danber.  (Unfortunately, the two
are slightly incompatible, so both sides need to have "t" or "e".  Both sides
also need to know how to establish a UUCP connection over the protocol in
question; in the 4.3BSD UUCP, at least, it's not done by faking up a login.)

The "t" and "e" protocols just send a file size indication followed by the data
from the file; they don't do any flow control or error
correction/retransmission of their own.  Over a protocol such as TCP/IP, this
is the way to go.  (Why duplicate the work that TCP/IP already does?)

> Remember also, that the tty line is in raw mode.  On V7 and (I think)
> BSD systems the reading program is woken up on each character.  This
> is very expensive to performance (and CPU utilization).

Yes, BSD systems tend to do this.  However, if you have a reasonable level of
input siloing in the tty driver, it will tend not to put characters on the
input queue one at a time, but will put them there in larger groups, say 14
characters on the average.  This provides a major performance win without any
changes to UUCP.

> The System V (and III) tty driver was modified to allow buffering of
> characters read, even in raw mode.  Hack this into your V7/BSD system.
> If you have a non-System V UUCP on your SV system that fails to take
> advantage of this feature it should be enhanced.

As Honey DanBer cranks the VMIN up to 64 under some circumstances, this could
conceivably reduce the CPU overhead even more.  I can't find the S5R2 source
anywhere, so I don't know what it does here; the 4.3BSD UUCP, when compiled for
a system with the S3/S5 tty driver, appears to be set up to do the same.