Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!rpi!uwm.edu!rutgers!att!dptg!mtunb!jcm
From: jcm@mtunb.ATT.COM (John McMillan)
Newsgroups: comp.sys.att
Subject: Re: BNU uucp e protocol anybody?
Summary: 1) e - YES! 2) TrailBlazer -- think twice!
Message-ID: <1718@mtunb.ATT.COM>
Date: 7 Dec 89 14:25:44 GMT
References: <1847@neoucom.UUCP>
Reply-To: jcm@mtunb.UUCP (John McMillan)
Organization: AT&T ISL Middletown NJ USA
Lines: 32

In article <1847@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes:
>Hello group.  I was just wondering if anyone out there has tried
>out the uucp e (e for error-free link) protocol .. especially on
>the 3b1.

	'E' is used extensively in our 3B1 HDB StarLAN transfers.
	Very fast -- about 3 times as fast as 'g', if I recall
	properly.

>The e protocol requires that an error free machine-to-machine link
>exist.  In the 4th quarter Unix release notes, AT&T actually
>mentions using the e protocol in conjuction with the CEO 2224
>modem's MNP error correction.  e doesn't bother ACK'ing each 64
>byte packet the way the g protocol does; e transmits the entire
>file.
>
>Using the BNU uucp on the 3b1 with g protocol spoofing supported in
>the Trailblazer modem results in xferstats of around 1200-1250
>characters/sec for me when the EIA port is pushed to 19.2K buad.  I
>tried the e protocol, and got xferstats of about 1350 char/sec.  In

	Didn't you mention "an error free machine-to-machine link..."?
	The RS-232 ports on the 3B1 are *NOT* an error free link.
	It is trivial to overrun the ON-CHIP buffers during other
	RS-232 output operations [incl. the phone use].

	In an environment where one can guarantee NO character losses
	between the kernel and the modem, the 'e' protocol might work
	-- but it's not going to happen on the 10MHz, overburdened
	68010 of the 3B1.

john mcmillan -- att!mtunb!jcm