Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!bionet!agate!shelby!rutgers!att!cbnews!mjs From: mjs@cbnews.att.com (martin.j.shannon) Newsgroups: comp.dcom.modems Subject: Re: USR 9600 baud dual standard Summary: 'e' protocol is very different! Message-ID: <1990Oct9.161454.10476@cbnews.att.com> Date: 9 Oct 90 16:14:54 GMT References: <1990Sep30.024433.28717@athena.mit.edu> <2461@van-bc.wimsey.bc.ca> Organization: AT&T Bell Laboratories Lines: 61 In article <2461@van-bc.wimsey.bc.ca>, sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: > 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. I beg to differ. 'e' protocol does *NO* *ERROR* *CHECKING*. This is why, *WHEN* *USING* 'e' protocol, one needs an error free link between the uucico programs, including anything to do with the serial ports. > Hardware flow control (also know as RTS/CTS, hardware handshake etc) is > *NOT* needed for uucp. True, iff you're using 'g' protocol (the default). > van-bc run's 2 PEP modems with baud rates locked at 19.2. With no flow > control. Great! But I don't use a Telebit, so I can't do PEP, and I don't have uucp 'g' protocol spoofing in my modem. > 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. Yep, that gives about 140 millisecs minimum interrupt latency for a bit rate of 14400 bits/sec. > uucico sends up to 3 64+7 byte packets and then stops and waits for an > acknowledgement packet from the other end. Again, this is true for 'g' protocol, but *NOT* for 'e' protocol. > 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. But, even better, 'g' protocol will keep trying to send a packet *UNTIL* it gets the appropriate ack. So, in reality, all you really need is to be able to receive a single packet intact at a time. > 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. Call that 71 (64+7) bytes and specify that you're talking about 'g' protocol, and I don't have any argument. > 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. Except that the original article was specifically about modems that *AREN'T* PEP capable. Did you read any of it? Sheesh! -- Marty Shannon; AT&T Bell Labs; Liberty Corner, NJ, USA (Affiliation is given for identification only: I don't speak for them; they don't speak for me.)