more on the HFC saga

Thaddeus P. Floryan thad at public.BTR.COM
Tue May 14 21:49:26 AEST 1991

In article <1991May13.010730.4743 at fithp> mhw at fithp (Marc Weinstein) writes:

	To all those who are still interested...

	We've discovered quite a bit over the last few weeks about Hardware
	Flow Control on the 3b1.  If the below findings are common knowledge
	to some, such is life.  If anything is incorrect, please post a


Sigh, no correction needed.  Details of purchasing a company 6 weeks ago have
kept me away from the net for awhile, so I've a bunch of catching up to do.  As
an aside, as part of that acquisition and attempting to bring up a Sun 3/60 to
SunOS 4.1.1, an SGI IRIS with IRIX 3.whatever, a PS/2-80 with A/IX 1.2.1, etc.
I've gained a new appreciation for how GOOD the 3B1/UNIXPC really is and how
EASY it is to install and/or upgrade system software on the 3B1; those other
systems suck dead bunnies through a straw in that regards in my opinion.

(I also saw the post re: 3B1 and Sun 3/60 Ethernet, and since I just acquired
and upgraded a Sun 3/60 to SunOS 4.1.1, I'll try out the rcp, et al by taking
one of my 3B1 in to the office and "seeing what happens" :-)

In any event, my original posting started this thread (ref: 1800 cps output
and 75 cps input using HDB at 19200 baud after 6KB or so of uucp'ing; that 75
cps was due to constant "Alarm n" after each subsequent block transferred
followed by a 10-second wait thus driving the cps rate down to the floor,
lower than even the proverbial whale turds :-).   A quick grep on the extant
newsgroup files here at BTR shows many others have confirmed those stats.

My own tests with extremely sophisticated DLM and other RS-232 test equipment
confirm beyond a shadow of a doubt:


I first discovered this in 1987 with 3.51 and re-confirmed this in 1991 with
3.51m; tests were run on ALL of tty000 through tty004, with stock V2 UUCP and
the 3B1 HDB UUCP, and xmodem/ymodem/zmodem and "cat" transfers.

Recent private conversations with "people who should know" (:-) have elicited
the info that HFC on *INPUT* is *NOT* implemented in *ANY* kernel that CT has
produced.  Many (most?) of CT's systems were 68020-based, and the *NEED* for
HFC at 19200 was non-existent as proved by my own tests on two MightyFrames;
as an aside, HFC at 38400 on the MightyFrames is also not needed except for
worst-case zmodem transfers where, in my tests, I encountered only ONE serial
port overrun in over 200MB file transfers during the tests.  And, again, from
a "person who should know", examination of the kernel source code verifies
that INPUT HFC is non-existent; output HFC is compiled-in and works just fine.

And as for the one abusive respondent who claims that 19200 baud works just
fine and that I was full of it, I wonder what he's smoking?  I have read in a
private email (cc'd to me) that with a 3-wire (2,3,7) direct 19200 baud serial
connection between his (the abusive respondent's) 3B1 and an NS32532-based
Minix machine he gets 700-750 cps; yeah, sure, that's a high-quality 19200
baud connection all right; hot damn!  :-)

And for those who've forgotten, here's the crucial (non-abusive) part of the
abusive respondent's posting to comp.sys.3b1 re: my original posting in regards
to 3B1 operation at 19200 baud:

	Funny, my TrailBlazer Plus, still with creaky old 4.00 ROMs, has been
	running just fine with hardware flow control and an interface locked
	at 19,200 for several *years* now.  Currently traffic levels are near
	three-quarters of a *gigabyte* per month with nary a trace of data
	loss.  (There may be an occasional HFC hiccup but uucp's g protocol
	obviously deals with it and even at that the data rates show minimal
	impact from retries.  HDB uucp, BTW, not the stock garbage.)

	For the record, I happen to have some numbers for Tuesday of last
	week, an entirely ordinary day for ******** [site name deleted] with
	respect to uucp.  That day a total of 24 megabytes was transferred
	in and out over the modem in just over 7 hours.  Outbound traffic
	outweighed inbound by about 1.24 to 1 and these numbers include a
	non-trivial amount a 2400 baud traffic (perhaps even a trace of 1200)
	along with some PC Pursuit in addition to Telebit (PEP) links.  Despite
	all that when one accounts for g-protocol packet overhead the *average*
	rate is over 1,000 bytes per second.

Using my calculator, 24MB during 7 hours equates to 952 cps, which is about
what I get with my T2500 locked at 9600 baud on the 3B1 for a mixture of email
and large uucp file transfers.  Even considering the 2400 and 1200 baud
connects, that is NOWHERE'S near the 1850+ cps over the modem (even faster
using direct hard-wired connections) I do get using systems that CAN and DO
support 19200 baud correctly (e.g. my Amigas (which are 68020-based) or the CT
MightyFrames (also 68020)).

A properly functioning 19200 baud connection is capable of "almost" 7MB per
hour (6.9MB actually) which, for 24MB, should have required only 3-1/2 hours
at most, half the 7 hours (or twice the speed) as stated in the posting extract
included above.

Twice as long is the same as half the speed.  Hmmm, half of 19200 is 9600, and
with 10 bits per character is 960 cps.  Double hmmm.

Phooie!  If you believe that 750 cps (or even 952 or 1000 cps) is a correctly
functioning 19200 baud connection, I have some ocean/beach-front property in
Arizona I'll be happy to sell you, or you can buy my option on the Brooklyn
Bridge for $1,000,000 in small, unmarked bills!  :-)

The 700-750 cps data rate is about the maximum my own VAX-11/780 systems
can pump out at 19200 with NO other load on the system.  If one is going to
test 19200 baud operation, one damn well better be using systems that are
CAPABLE of 19200 baud operation; the 3B1/UNIXPC is NOT.  As for testing, as
posted previously, I do have and use the proper test systems since I sell
commercial modem-interface products of my own design and manufacture to phone
companies, the US Govt, and others.

This is the real world, not a chapter from "Peter Pan"; closing one's eyes and
wishing real, *REAL* hard, is *NOT* going to make one's dreams come true.  As
much as I like the 3B1 (I have a LOT of them! :-), it simply does NOT support
19200 baud in a consistently reliable manner on the 3B1.

Sheesh, haven't YOU ever wondered WHY "19200" isn't in the 3B1's serial port
baud UA setup menu?

Thad Floryan [ thad at (OR) {decwrl, mips, fernwood}!btr!thad ]

More information about the Comp.sys.3b1 mailing list