jbrown@jato.Jpl.Nasa.Gov (Jordan Brown) (09/23/88)
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? :-)
dave@arnold.UUCP (Dave Arnold) (09/23/88)
(Jordan Brown) writes: > I haven't decyphered it enough to figure out if this is a > negotiated parameter... There is no negotiation in g. Each side tells the remote what it's receiver is capable of, and the remote is supposed to comply. In other words, you say, "Hey, send me 256 byte packets, and set your transmit window to 7". Keep your fingers crossed. It seems to work with System V.1 though. But you see, no negotiation. > uucps run exclusively at 64 bytes/packet? Not, all, but I suspect most. Remember, how big is your typeahead buffer? Let's see... 1024 * 7 windows = ... BIG. > Does anybody reading this understand the guts of 'g'? I'm getting there. > 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? :-) I suggest we start up comp.protocols.uucp. -- Dave Arnold dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!dave
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (09/25/88)
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
gnu@hoptoad.uucp (John Gilmore) (09/26/88)
The packet size is negotiated in powers of two; it is possible to
negotiate larger packet sizes. I have not tried it in gnuucp, but
it should work. Last time this was mentioned though, someone
reported that old Unix uucp's would happily try to send you larger
packets, but had statically allocated buffers of the old size --
so they end up overrunning an array, writing into random memory, and
crashing.
It's not clear what effect larger packet sizes would have. On
links that have high delay (e.g. PC Pursuit), the more data you
can shove into the pipe before stalling awaiting an ack, the better
off you are -- so since the protocol limits you to 7 packets,
making them larger is a possible way to increase thruput. On links
with fast acks (any Telebit link, and links to quick systems), it
probably doesn't matter much.
Somebody pointed out a problem if uucico "swaps out" and you use large
packets, the tty drivers won't have room to keep all the characters.
That depends on your tty drivers of course, but regardless, if your uucico
is swapping out, your thruput is going to go to shit anyway because your
acks are delayed and the sender stops sending.
I recommend that if anyone implements larger packet sizes, you call it
the "G" protocol rather than the "g" protocol. That is, the "G"
protocol is a "g" protocol that has no bugs around large packet sizes.
Advertise as supporting both; if you call another site with no bugs,
you'll use large packets, and if you call an older site, you'll use the
old standby 64 byte packets.
John Gilmore
--
John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com
there's still time to change the road you're on. --LZ: "Stairway to Heaven"dave@arnold.UUCP (Dave Arnold) (09/26/88)
gnu@hoptoad.uucp (John Gilmore) writes: > The packet size is negotiated in powers of two; it is possible to > negotiate larger packet sizes. I just wanted to point out that there really isn't any "negotiation" in g. Simply, each side tells the other what to send. Period. The other side is supposed to "Comply". Now if there was a dialogue, such as -> Send me 1024 byte packets <- Unable to Send you 1024 byte packets but can send you 512 -> Please send me 512 <- Sending 512 ... I suppose the INITC message offers some kind of negotiation. That is, after the window size, and packet size have been set in the transmitter, a INITC can reset your transmit window. > It's not clear what effect larger packet sizes would have. On I don't know about dialup links---But some statistics I've seen regarding configuring X.25 packet layer packet sizes, the larger, the better. Assuming it's a clean link. -- Dave Arnold dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!dave