From: gerg@netcom.com (Greg Andrews)
Subject: Re: UUCP 'g' must die 
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Thu, 15 Oct 1992 03:16:22 GMT

mrapple@quack.sac.ca.us (Nick Sayer) writes:
>gerg@netcom.com (Greg Andrews) writes:
>
>>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):
>
>If it is possible to train Taylor to use larger packets, it's
>a mystery to me. It's stuck at 64x7 for me. 
>

Last time I looked, it was one of the things you could adjust in one
of the Systems/Devices/Dialers/Whatever files.  Have you asked about
this in comp.mail.uucp, or talked with Ian about it?

>
> And even if I use large packets, it's a crap shoot whether:
>
>A. My neighbors will force 64x7, undoing all the work.
>

Their packet parameters can't override yours.  See (C).

>
>B. My neighbors will segfault because the crappy implementations they
>have can't figure out 1024x3 (or better yet 1024x7).
>

Then they'll need another uucico.  What, then, will be the difference
between them compiling a more capable uucico and compiling a new protocol?

>
>C. It'll be 64x7 one direction and 1024x3 the other
>

Probably this, if their uucico doesn't break trying to serve you larger
packets.  One direction will run more efficiently than the other, and
the more efficient direction will be where you receive.  They will ask
for the standard 64x7 when you send to them, and they'll get it, warts
and all.

>
>or
>
>D. It'll work.
>
>I'll stipulate your calculations, but they are merely academic
>unless you can get the damn thing to USE large packets.
>

So is a different protocol.  Useless if the other guy doesn't have it too.

>
>>IMHO, we don't need to throw 'g' away.  We just need to write better
>>implementations, like SVR4 and Taylor.
>
>IMHO, The likelyhood of fixing the problem is higher with a replacement
>protocol. One strongly designed so that hopefully lazy implementers
>can't make do with getting it 'close' like so many have with 'g'.
>

Lazy implementors can be just as lazy with a new protocol as with an
old one.  However, I don't see this as a crucial issue.  Your uucp
neighbors will have to get new code and compile it anyway.  Whether it's
a better implementation of 'g' or a new implementation of something else,
they'll still have to go through the same amount of work.  Either way,
you'll be faced with the same incompatibility problems if their uucico
can't do the same things yours can.  You'll have to back down to the same
Lowest Common Denominator:  64-byte/packet 'g'.

I'll agree that in 1992, standing on the shoulders of others, you can build
a protocol that can run as fast or faster than 'g' without most of its
shortcomings.  However, when your protocol hits the streets, the end users
are going to have the same problems compiling it and using it with their
neighbor sites as they would have with an improved implementation of 'g'.

If I were trying to get the attention of Unix vendors, should I advocate a
new protocol, or a better 'g'?  Being vendors, they'll worry that the market
would take a different direction than the one they choose.  They'll be looking
for indications about which way the market will go, setting the standard for
the next few years (even if just a de facto standard).  I haven't seen much
in the way of indicators for new protocols, but I have seen SVR4 come out with
"G".  Given the choice between a new protocol and the improved version of 'g'
that comes with the ballyhooed SVR4, I think most vendors would pick the one
that will make them the most compatible with SVR4.


That's my viewpoint.  You can design a better protocol, but you can solve
the throughput issues and be more compatible with the future and the past
by writing a better version of 'g'.  I'd rather improve 'g' than create a
new protocol.


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