[net.news] Making uucp/news go faster

trt@rti-sel.UUCP (03/24/84)

Here is a performance hack that did not make it into 4.2 uux:
	if (argc > 2) {	/* rti-sel!trt: avoid gwd() for trivial case (rnews) */
		ret = gwd(Wrkdir);
		if (ret != 0) {
			fprintf(stderr, "can't get working directory; will try to continue\n");
			strcpy(Wrkdir, "/UNKNOWN");
		}
	}
	DEBUG(4, "\n\n** %s **\n", "START");
[Note: the placement of this code is important.  The old ``gwd'' code
appears later in uux and should be removed.]
Avoiding the ``gwd'' call avoids a fork(II), an exec(II) of sh(I),
another fork(II), an exec(II) of pwd(I), and a few other things.
(The performance effect was never measured.  After all, it's a hack.)

Alas, Mark Horton's speedup-by-sleeping hack never got into 4.2 uucp either.
But I am not convinced it helps.  Anyone care to rerun Mark's tests of it?

I think what really ticks people off is that letters can get hung up
for hours waiting for uucico/uuxqt to finish processing all the news.
Using Mark Horton's ``grade'' option helps the uucico part,
but uuxqt never sees the grade information when it is ordering
the X. files for processing.
That has been fixed in Honey DanBer uucp, probably with a hack to uux
to include the grade letter in the 'X.' filename.

As for phone line overhead, the only ease cure is to batch news
into small numbers of large files, and ship those.
Here is what uucico does to ship a *single* file:
	Master:	I wanna send D.rti-selB1234	(70 bytes)
	Slave:	OK				(70 bytes!!)
	Master:	... here is the file ...	(N bytes + ~32 bytes slop)
	Slave:	TNX				(70 bytes!!)
Even with zero dead time the overhead is substantial at 1200 baud.
A uux-shipped news article requires sending an 'X.' and a 'D.'.
Some batching schemes do not send an 'X.' but still send each
article as a separate 'D.'.  To save phone time the articles
should be concatenated (and compressed) into large files.
Wouldn't it be nice if there were a ``uubatch'' command
with syntax and semantics essentially identical to ``uux''?
Ah well, there's never time to code but there's always time to flame.
	Tom ("still waiting for a fix") Truscott