Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!ncrlnk!ncr-sd!hp-sdd!ucsdhub!ucsd!ames!mailrus!cornell!uw-beaver!ubc-cs!van-bc!sl
From: sl@van-bc.UUCP (pri=-10 Stuart Lynne)
Newsgroups: comp.mail.uucp
Subject: Re: 'g' packet size
Message-ID: <1893@van-bc.UUCP>
Date: 24 Sep 88 21:25:09 GMT
Article-I.D.: van-bc.1893
References: <212@jato.Jpl.Nasa.Gov>
Reply-To: sl@van-bc.UUCP (Stuart Lynne)
Organization: Wimsey Associates, Vancouver, BC.
Lines: 48

In article <212@jato.Jpl.Nasa.Gov> jbrown@jato.jpl.nasa.gov (Jordan Brown) writes:
>How practical is it to increase the packet size on a 'g' transfer?
>About 10% of a g transfer is header overhead (6 bytes header, 64 bytes
>data); it should be quite practical in terms of reliability to go to
>much larger packets (maybe as large as 1k, which works fine for ymodem)
>and reduce the overhead dramatically.
>
>My UUPC source indicates that it should be easy to go to at least 128,
>but the real question is whether any other site in the universe will do
>it.  I haven't decyphered it enough to figure out if this is a
>negotiated parameter... if it isn't I guess I'm sunk.  Do all known
>uucps run exclusively at 64 bytes/packet?
>
>(Yeah, I know it's only 10%, and probably only 5%.  But if it's easy,
>why not do it?)
>
>Does anybody reading this understand the guts of 'g'?
>
>Doesn't seem like this should go on comp.mail.*, but there aren't any
>other groups that look good.  (Besides, does anybody do anything else
>with uucp other than news and mail? :-)

It would be fairly easy to implement but the problem lies in getting
everyone else to also switch. The vast majority of uucp sites don't have
access to source.

One other point about changing packet or window sizes. The 64 bytes times 3
packets fits well into the tty driver / line discipline's idea of how much
data to accept before flushing the buffers. If uucico get's swapped out and
the data doesn't get pulled out of the driver's clist's the sender will
automatically stop sending after three packets. Increase the packet or
window size and he keeps sending, and the line discipline will flush the
clists. 

In the first case when uucico comes back in it will receive and then ack the
packets queued and things start up very quickly. In the second case we have
to wait for the sender to time out and resend (usually about ten seconds).

The bottom line is 64 x 3 is a compromise of more than just line use but of
other systems resources as well. In this case driver clist's. And if you
were to change the one you probably should change the other. Again given the
lack of source for the kernel at most sites it will be hard for them to
increase the buffer space and modify line discipline zero to allow the use
of more clists to buffer data.


-- 
Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl     Vancouver,BC,604-937-7532