Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!gould!jfraser
From: jfraser@gould.UUCP (Jonathan Fraser)
Newsgroups: comp.mail.uucp
Subject: other uucp proto's
Message-ID: <1766@gould.UUCP>
Date: 9 Mar 89 22:47:53 GMT
Distribution: usa
Organization: Gould CSD, Fort Lauderdale, FL
Lines: 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.