Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!zaphod.mps.ohio-state.edu!van-bc!sl
From: sl@van-bc.wimsey.bc.ca (Stuart Lynne)
Newsgroups: comp.dcom.modems
Subject: Re: USR 9600 baud dual standard
Message-ID: <2461@van-bc.wimsey.bc.ca>
Date: 9 Oct 90 05:47:08 GMT
References: <1990Sep30.024433.28717@athena.mit.edu> <1990Sep30.211908.558@spcvxb.spc.edu> <1990Oct8.195418.1817@cbnews.att.com>
Organization: USENET Public Access, Vancouver, B.C., Canada
Lines: 36

In article <1990Oct8.195418.1817@cbnews.att.com> mjs@cbnews.att.com (martin.j.shannon) writes:

>Yes, the problem is the UUCP g protocol.  That is fairly widely accepted.
>I get 97% of the available bandwidth using the 'e' protocol.  Of course,
>using it requires an error-free link between the uucico programs -- that
>includes hardware flow control.

No. False. Incorrect. Wrong. Negative. Bad assumption.

Hardware flow control (also know as RTS/CTS, hardware handshake etc) is
*NOT* needed for uucp.

van-bc run's 2 PEP modems with baud rates locked at 19.2. With no flow
control.

The only requirement is that each end of a uucp connection have the normal
amount of bufferring that was offerred in the old style tty drivers.
Specifically about 255 bytes. 

uucico sends up to 3 64+7 byte packets and then stops and waits for an
acknowledgement packet from the other end.

As long as there is no place in the chain between the sender and the
receiver (where the ack's are generated) that has less than about 220 bytes
of buffer nothing will be lost because that's the most uucp will send.

If you have a constricting point that has less than 220 bytes of bufferring
then yes it is a good idea to put hardware handshake into effect.

For the default case of two Unix boxes hooked directly together, and for use
with PEP modems there is always enough room. You should not need to have
hardware flow control. 

-- 
Stuart Lynne	Unifax Communications Inc.
		...!van-bc!sl 604-937-7532(voice)     	sl@wimsey.bc.ca