jfraser@gould.UUCP (Jonathan Fraser) (03/10/89)
I've been toying with getting higher throughput with V.32 modems with uucp. These are my conclusions. This is based on BSD4.2/RTI uucp. 1) 'g' protocol must remain intact at it is. I think most everyone would agree with this, particularly all those binary sites. 2) the major problem with throughput is packet size. g proto is supposed to negotiate packet size but does not. This is not just a matter of data buffer sizes and #defines. It only works if boths sides have the same max packet size and only negotiates to the max. You can't have one side with 64 bytes packets and another with 256 bytes packets. 3) It may not be impossible to fix packet size negotiation in a backward compatiable manor, but nobody has been able to do it. I got it to work if I was the master, but not as the slave and it's quite messy. 4) f protocol has too much overhead converting 8 bit chars to 7 bits to work on 7 bit channels. 5) t protocol doesn't quite hack it even on very reliable modems. The speed is fast, but once uucico starts sending data, you can drop the line and uucico just keeps on going. You still need some end to end packetizing and checking. What I've done is invent 5 'new' protocols. These are just 'g' with different max packetsizes. proto size a 256 b 512 c 1024 d 2048 e 4096 g 64 (unmodified) In effect, you are negotiating packet size when you negotiate the proto. The packet size gets passed to 'g' and 'g' starts up with the appropriate packet size. If you have a standard uucp, you can't select a-e, so standard g gets used. Why bother with more than one packet size? Is bigger not better? My microcon V.32 modems use 256 byte blocks. Performance appears better at 512 and 1k blocks than at 2k blocks. Other modems may have similar performance quirks. The max packet size or protocol is determined from the L.sys and L-devices entries. The proto letters a-e follow ACU. e.g. ACUb, ACUe. L.sys: scorch Any ACUc 38400 annex "" "" annex: r\sscorch ogin:--ogin: L-devices: ACUe acu05 acu05 38400 hayestone ACUe acu05 acu05 19200 hayestone ACUe acu05 acu05 9600 hayestone ACUd acu05 acu05 2400 hayestone ACU acu05 acu05 1200 hayestone In this case, uucico selects an ACU at 38400 with class >= 'c'. When it negotiates with the other end, it will only select 'a', 'b', or 'c', or, of course, 'g'. I haven't added any smarts on the slave end about picking a protocol. At the moment, I'm making the assumption that the type of modem at the receiving end is known when adding the L.sys entry and that all modems on a rotary are the same type. Of course, you can have two L.sys entries for the same site with two different classes and two different numbers to call. I haven't tried starting up uucico with roles reversed. I suspect you'll end up with 'e' or 'g' protocols. I will check. Unfortunately, there's no reliable way to know on what modem you've been called. As as example, when calling 'scorch' above, the modem is on an Annex ethernet terminal server and uucico does an rlogin after connecting to the annex! Microcon V.32's have built-in data compression. Sending data via uucp that has already been compressed, I can get about 900 bytes/second. Sending uncompressed data (/etc/termcap), I've seen as high as 2000 bytes second. Using 'g', I top out at about 450 bytes/second on the same modems. If you have specific questions/comments you want answered right away, please email me at uunet!gould!jfraser.
honey@mailrus.cc.umich.edu (peter honeyman) (03/13/89)
honey danber has first dibs on d (datakit) and e (error-free). getdxf is the complete string known to me. are there others? peter
emv@a.cc.umich.edu (Ed Vielmetti) (03/13/89)
In article <1000@mailrus.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >honey danber has first dibs on d (datakit) and e (error-free). >getdxf is the complete string known to me. are there others? 'm' protocol runs over Merit links (let's see, 7E1 and a few control character reserved). mike berenson hacked it up. mail mike@mbsun.ann-arbor.mi.us for details.
aeh@sfsup.UUCP (+Herzog A.) (03/14/89)
In article <1766@gould.UUCP>, jfraser@gould.UUCP (Jonathan Fraser) writes: > > 1) 'g' protocol must remain intact at it is. I think Absolutely! Or at least it must be compatible with the maximum (implementation imposed) packet size of 128. Is this different for anyone else out there? > 2) the major problem with throughput is packet size. This appears to be true, at least with devices I've seen, although I have also seen window size play a big role, especially on error-prone connections. > g proto is supposed to negotiate packet size but does not. Actually, 'g' protocol does not negotiate packet size. The 'receiver' simply states the packet size to be used, and the 'transmitter' is expected to comply. The same is true in the other direction of data flow. > This is not just a matter of data buffer sizes and #defines. > It only works if boths sides have the same max packet size > and only negotiates to the max. You can't have > one side with 64 bytes packets and another with > 256 bytes packets. This does not seem to be true. The #define was definitely a problem. But now we have 64 byte packet uucicos talking with 256 byte packet uucicos. The protocol is designed to allow this. This lets one direction be optimized for data transfer, and the other for message transfer. > 3) It may not be impossible to fix packet size negotiation > ... > What I've done is invent 5 'new' protocols. These are The 'd' protocol is reserved in HDB, and so is 'e'. If you talk to other machines which know these, don't expect much. Don't forget the 'f'. Any others out there we should worry about? > proto size > a 256 > b 512 > c 1024 > d 2048 > e 4096 > g 64 (unmodified) In SVR4, so will 'G'. The 'G' will be the SAME as 'g' with the maximum allowable packet size permitted by the protocol (4096). > In effect, you are negotiating packet size when you negotiate the proto. Better to negotiate a protocol, and then let it handle the internals?! The only trick is to set the parameters (packet and window size) at run time. This can easily be done by using the ",eg" protocol subfield of the device type field of the Devices (and/or Systems) file. > Why bother with more than one packet size? Is bigger not better? Apparently not. Even with very fast media, there are other limitations which cause this to not be true. The key is to make the implementation flexible enough so the administrator can make the decision at run time. With the right combination of parameter settings, the throughput can be increased significantly. Of couse, choose the wrong values, and all bets are off. -------------------- /* As usual, what I said is what I said: nothing more, nothing less. */
dg@lakart.UUCP (David Goodenough) (03/15/89)
honey@mailrus.cc.umich.edu (peter honeyman) sez: > honey danber has first dibs on d (datakit) and e (error-free). > > getdxf is the complete string known to me. are there others? > > peter Upg is the protocol request string lakart gets from xait.xerox.com. So I guess that there is a 'p' protocol, or xait is waiting to have it's bluff called. -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+