The "Final" Word on 3b1 HFC

[Thaddeus P. Floryan]

In article <1991May19.030549.3983 at ims.alaska.edu> floyd at ims.alaska.edu (Floyd Davidson) writes:
{comments re: HFC on the 3B1 per the extractions:}

>	Maybe it does, maybe not. but...
>	[...]
>	HFC doesn't have anything to do with the rate of data transfer
>	between the modems.  The sending modem is NOT going to detect
>	anything as a result of the receiving modem asserting HFC.
>	[...]
>	I would suggest that anyone else who wants further
>	information on this should bring it up in the comp.dcom.modems
>	group.

Let's not mingle two issues here (HFC and modem transfers).

Incoming HFC on the 3B1 simply does NOT work no matter whether one is directly
connected with hardlines or receiving via a modem.  Besides the fact my own
tests (in 1987 and 1991) indicate it doesn't work, comments from "reliable
sources" (no pun) indicate the incoming HFC code has NOT been compiled into
the distributed code (due to #ifdef ...(and (presumably) untested routines)).

Outgoing HFC works just fine on the 3B1, both over hardlines and modems. Thus
I disagree with the comment above re: "...sending modem is NOT going to detect
anything..." because calling from my office at 2400 baud into a T2500 connected
to my 3B1 (fixed at 9600 baud) works just fine ... the 3B1 does "somehow"
detect my office computer's HFC signal to STOP to prevent its (the office
computer's) buffer from overflowing when the 3B1 is sending at 9600 baud but
the office computer is receiving at 2400 baud.  Magic?  Swinging dead chickens
over one's head while dancing under a full moon in one's Jockey shorts?  Dunno.

The audience in comp.dcom.modems probably doesn't even know (or care) what a
3B1 and its problems are, so why burden them?

The 3B1 is one heckuva nice system (I have many of them), but it's NOT a
powerhouse by today's standards.  My 3B1 are (subjectively) faster than the
Mac II (68020) running A/UX at my office, but both my Sun and MightyFrames run
circles around most other systems I use on a regular basis.

For example, I've given up optimizing streaming tape I/O on the 3B1 with double
buffering techniques because the disk I/O on the 3B1 seems to be the bottleneck
as shown by running the "diskperf" program (originally designed to test Suns).
The max on the 3B1 (ANY disk) is about 55KBytes/sec which is too slow to stream
the tape drive; the MightyFrame's stats simply went off the scale (the same
program) at over 350,000 bytes/sec.  The ephem program which I run daily on
my 3B1 calculates to the exact same results on both the MightyFrame and Sun,
but the MightyFrame version seems about 100 times faster (the 3B1 is about the
same speed as my VAX-11/780, though, for this calculation! (planetary orbits,
astronomical coords, rise/set times, etc))  (Yet, strangely, the 3B1 can do,
say, an uncompress, faster than my '020 Amiga whose diskperf is 650Kbytes/sec;
must be a factor of single-threaded vs. multi-threaded file systems; comments?)

Point being: the 3B1 doesn't have enough "horsepower" to handle thousands of
interrupts per second.  This point slammed home quite clearly earlier today
when "someone" attempted a uucp transfer from my system while a tape backup
was ongoing ... uucp (HDB (over serial line)) just simply up'd and died.  As
a reference point, my VAX-11/780 cannot do it either, and the 3B1 (in my
opinion) has better serial I/O capability than the VAX with its DZ-11.  But
do you see me selling off my 3B1s?  NO!  I accept the fact the serial I/O is
limited to 9600 baud (still better than my VAXen) and ENJOY all the other great
things of which the 3B1 IS capable (gcc, emacs, email, klondike, etc. :-)

Even though my own MightyFrames (two) haven't yet shown problems at 19200 (or
even 38400), CT *DID* manufacture a "Terminal Accelerator" for those systems
to even further improve serial I/O performance (and, no, I don't have a "TA"
in either of my systems, but considering the MightyFrame's Ethernet cards have
a dedicated MC68010 (which is the 3B1's PRIMARY CPU) just to handle the Ether
stuff, I wouldn't be surprised to learn the "TA" card also has a 68010.  Even
the Apple laser printers have dedicated 68020 CPU's to handle the PostScript
stuff connected to a system sporting just a 68000 as its PRIMARY CPU).)

If you want speed, get a "box" boasting a 68040, 88K, R4000, etc. and be
prepared to spend Big Buck$, and be faced with a possibly "immature" kernel.

If you want a neato (and affordable, solid and reliable) UNIX box, get a 3B1.

I *LIKE* the 3B1 and its kin, and have put MY money where my mouth is, now
owning seven (7) 3B1, two MiniFrames, two MightyFrames, one Sun, one Iris,
one PS/2-80 (w/ AIX), several Amigas (68000, 68010, 68020), and some other
systems including the VAXen, and I expect the 3B1 systems in my "stable" to
outlast ALL those others.

For 25 years up to four years ago, I was a "DEC diehard"; no longer.  The
3B1 and its user/owner community reminds me so much of the ORIGINAL hacker
community of the '60s that ... wellllll, no need to get maudlin here.  Damn!
I wish AT&T didn't screw the 3B1 marketing so badly; well, my commercial
software products should soon appear on the 3B1's brethren and kindred souls
after decades on the DEC machines (PDP-10, DEC-20, and VAXen).

And I'm gonna have at least one 3B1 in this year's West Coast Computer Faire,
May 30 - June 2, at Moscone Center in San Francisco in the AT&T Users' Group
booth!  If you're in the area, gimme a call as I have discount admission
tickets, and if you can help in the booth (4 hrs max) I'll get you in for free.

And, no, I am NOT employed by AT&T, CT, UNISYS, Motorola, Apple, etc. (though
they and others DO buy and use my software products).  As a final disclaimer,
I do own 25 shares of AT&T stock (which I bought back in 1965 or so when I
worked for GTE's Electronic Defense Labs :-)

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