ctwomey@ccvax.ucd.ie (09/04/90)
Another question about uucp over X.25! My understanding of the difference between the 'g' and 'f' protocols is that the 'f' protocol does a minimal amount of data checking and the 'g' protocol does a lot of packetising and data checking. Now assuming that I have two machines linked via modems and PADs using an X.25 connection, and the connection is such that the PADs ignore all interpretation of characters essentially entering binary mode, why exactly does the 'f' protocol work and the 'g' protocol not? (Remember ^P is being ignored by the PADs.) Hopefully someone can explain this to me or indicate where I can find this information. Colum Twomey, Computer Centre, University College Dublin, Ireland. ctwomey@ccvax.ucd.ie
jim@lsuc.on.ca (Jim Mercer) (09/06/90)
In article <6706.26e3ab4f@ccvax.ucd.ie> ctwomey@ccvax.ucd.ie writes: >Another question about uucp over X.25! > >My understanding of the difference between the 'g' and 'f' protocols >is that the 'f' protocol does a minimal amount of data checking and the >'g' protocol does a lot of packetising and data checking. generally, yes >Now assuming that I have two machines linked via modems and PADs using an >X.25 connection, and the connection is such that the PADs ignore all >interpretation of characters essentially entering binary mode, why exactly >does the 'f' protocol work and the 'g' protocol not? (Remember ^P is being >ignored by the PADs.) it's not that 'g' doesn't work, you just have to mung the X.28 parameters appropriately and maybe adjust your uucico window variable. i did extensive playing with this on a past project and finally achieved an average of 160 cps over 2400 baud X.25 links. two tricks: 1) under SCO Xenix 2.2, we adjusted the windows variable in uucico (using adb, yech!) from the default of 3 to 7. this means that as many as 7 (formerly 3) packets could be sent before the protocol would wait for an ACK from the first packet. opening the window allowed the ACK's to return before the protocol timed out. 2) X.28 parameters must be set to as transparent a mode as possible. no forwarding characters, forward on timer or full packet. also watch those flow control parameters. depending on the network (private, DataPAC, Tymnet, Telenet, etc) these parameters may change. 'g' over X.25 may not be as efficient as 'f', but at least 'g' is available in almost all uucp implementations. a pleasant request to postmaster@avcoint may get you in touch with someone who continued the effort (using X.25 on Hayes V series modems). ask for chris williams. -- [ Jim Mercer jim@lsuc.On.Ca || ...!uunet!attcan!lsuc!jim +1 416 947-5258 ] [ Systems Facilitator - Law Society of Upper Canada, Toronto, Ontario, CANADA ] [ Standards are great. They give non-conformists something to not conform to. ] [ The opinions expressed here may or may not be those of my employer ]
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/11/90)
In article <6706.26e3ab4f@ccvax.ucd.ie> ctwomey@ccvax.ucd.ie writes: >Now assuming that I have two machines linked via modems and PADs using an >X.25 connection, and the connection is such that the PADs ignore all >interpretation of characters essentially entering binary mode, why exactly >does the 'f' protocol work and the 'g' protocol not? There are really only three deciding factors in chosing between 'f' and 'g': - Transparency. 'g' needs a crystal-clear 8-bit path. There are an *amazing* number of PADs out there that cannot be configured to run 8-bit transparent, or at least not using runtime means like PAD parameters. - Throughput. For every 'g' packet sent, uucico must receive an acknowledge- ment. The window size (the number of concurrently unack'd packets allowed) is 3 for most uucico's, 7 for the newer ones. Often, the network delay to return the acknowledgement is greater than the time it takes to transmit all 7 packets. Even if you have properly raised the packet level window size above the default 2, you still tend to end up with uucico rushing out 7 packets, then snoozing until all 7 acks come in at once, then sending out 7 packets, etc. Some people on the net have done some serious tuning to improve throughput; see the other articles on this thread. - Costs. All those ACK packets and overhead of 'g' make it cost around three times as much as 'f', on text files. If you have really binary data (like the output of compress), you might get killed on all the quoting that 'f' has to do for 8-bit characters. Around here, we use the ~news/encode filter whenever shipping binary data over links known to use the 'f' protocol. <csg>