From: gerg@netcom.com (Greg Andrews)
Subject: Re: UUCP 'g' must die (was Re: USR DS v.32bis 10-15% faster thoughput over the Worldblazer)
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Tue, 13 Oct 1992 08:35:19 GMT

In article <fTKzq#e@quack.sac.ca.us> mrapple@quack.sac.ca.us (Nick Sayer) writes:
>gerg@netcom.com (Greg Andrews) writes:
>
>>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'.
>

I don't follow your reasoning.  You state that latency is a leading
cause for slow throughputs, but you don't want to adjust the protocol
to compensate?  You want to throw the whole protocol away?

Sounds like throwing the baby out with the bath water to me.

>
>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.
>

I'm not convinced that the two ends affect each other in a cumulative
fashion, as you're stating.  Even so, latencies of 30 milliseconds
are still far higher than I would expect from the modem's spoofer.

>
>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.
>

That's not the case.  The modems negotiate and use a window size of
3 in the computer-to-modem conversation.  Not windowless at all.

Besides, you're using Taylor uucp anyway.  Why the beef about the
Sun uucico of you've already replaced it with one that's more
capable?

>
>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).
>

But you're not using Taylor's support for larger packets to overcome
the latency issues and still recover from interrupt latency or flow
control errors?  Sounds like you haven't given 'g' a real chance to
prove itself in your situation.

>
>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.
>

I've pointed out (and you've agreed) that the design of the protocol
isn't at fault.  Larger packets handle all the issues you've raised.

The IMPLEMENTATION of 'g' is what is limiting you - not the design
of the protocol itself.  

Boost your 'g' parameters up to 1024x3 and look at the results
for V.32bis/MNP4 (Toby's figure of 1725 cps max):

  Packet/Window Size     Packet Efficiency         Latency Tolerance
--------------------------------------------------------------------------
    64x7  (70x7)        64 / 70   = 91.4%    414 / 1725 =  207 milliseconds
  1024x3  (1030x3)    1024 / 1030 = 99.5%   2042 / 1725 = 1021 milliseconds


The 414 comes from the equation  x = ((bytes/packet) * (window - 1)) - 6
for a 70 byte packet (64 data, 6 header) and a 7 packet window.  The 2042
comes from the same equation for a 1030 byte packet (1024 data, 6 header)
and a 3 packet window.

As you can see, 1024x3 has only .5% packet overhead, and it can handle
*5 TIMES* more latency than 64x7.


IMHO, we don't need to throw 'g' away.  We just need to write better
implementations, like SVR4 and Taylor.


-- 
 .------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {amdahl,claris}!netcom!gerg        |
 |                 |   Internet: gerg@netcom.COM                    |
 `------------------------------------------------------------------'