From: mrapple@quack.sac.ca.us (Nick Sayer)
Subject: UUCP 'g' must die (was Re: USR DS v.32bis 10-15% faster thoughput over the Worldblazer)
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
Date: Sat, 10 Oct 1992 17:14:23 GMT

gerg@netcom.com (Greg Andrews) writes:

>In article <fTxJwGT@quack.sac.ca.us> mrapple@quack.sac.ca.us (Nick Sayer) writes:
>>
>>My uucp results have, by contrast, been awful. I blame uucp-g
>>for this, and am fully convinced that it is time to throw g into
>>the shitter. If you're getting 1.3 kbps instead of 1.6 kbps and are
>>moving 20 MB of news per day, it's nearly an hour more connect time.
>>
>>I run UUCP spoofing on the WB with v.32bis/MNP4 and I _STILL_ get
>>1.3-1.4 kbps. That's just the way g is. 25% of your throughput is a
>>terrible thing to waste.
>>

>Uucp-g's overhead is not 25%.

That's not what I said. I said that I (and I don't seem to be alone)
am getting 75% of the effective throughput of MNP4 over v.32bis
when I run uucp-g.

>The packet overhead is only about 8.6%.

Which is a pretty dismal figure, but that is beside the point.

>It can run slowly if the modem's propagation delay is long enough, but
>spoofing or larger window/packet sizes will take care of that.

Latencies in modern high speed modems are very high indeed. The
ping time across a v.32bis/v.42bis PPP link is nearly a quarter
second (~64 byte packets). I don't really have a problem with
high latencies, except that high latency cripples typical
UUCP 'g' sessions. The solution isn't to go after latency, it's
to throw away 'g'.

Even if you use spoofing to get around modem-to-modem latency,
there's still the latency between the modem and uucico...
on EACH end of the connection. That latency shouldn't be
pooh-poohed. I'm pretty sure it's eating 25% of my throughput.
And it simply would not be a factor under a different protocol.

Your point about window an packet size is well taken, but OS
suppliers don't allow that choice. SunOS' uucico even comes stripped,
for crying out loud! And if you spoof, the session between the
modem and uucico is forced to be windowless 64 byte packets.

And even so... I'm using Taylor 'g'... 25%. If I use 'e' or 't',
I get full bore... Unless I get a UART error (which happens
every once in a great while, and from which 'e' and 't' can't
recover).

It's time for 'g' to 'g'o. Taylor 'a' is the best replacement I can
think of, but until and unless we demand en masse that OS suppliers
address the situation, we'll be stuck forever with a protocol
designed when speeds were an order of magnitude slower.

>How reliable was your measurement method?

Very.

>Did the modems have to re-transmit a lot of MNP packets?

No, but the problem isn't between the modems, it's between the hosts
and their respective modems.

>Are you sure the modems actually TURNED ON their spoofing?

Guaranteed (I debugged the chat script and saw spoofing flagged
in the connect message).

It amounts to this:

I've done my best. But my computer just can't do uucp-g at full
speed. It tops out at 1.45 kcps or so. And it's a Sun 4/25. It
doesn't do much else (certainly not during the measurement period).
Is my computer inadequate? I don't think so. Then if it's not the
computer, and it's not the modems, then it's either my neighbor
(who has a similarly powerful machine), or it's 'g'. I don't think
it's my machine or my neighbor, since if we run 'e' (and put up
with the occasional garble from a hit on the cable. We're talking
maybe once a week or two) we get 1.65 every time. It has to be
'g'.

'g' is dead. Long live 'g'.

-- 
Nick Sayer <mrapple@quack.sac.ca.us> | "Say, Stimpy, what's that on your
N6QQQ @ N0ARY.#NOCAL.CA.USA.NOAM     |  tongue?"
37 19 49 N / 121 57 36 W             | 	       -- Ren
+1 408 249 9630, log in as 'guest'   |