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