3B2/310 & TB+

[Stephen J. Friedl]

In article <16192 at ucsd.Edu>, brian at ucsd.Edu (Brian Kantor) writes:
> My experience with the 3B2/310 is that it can't handle 19200 bps
> sustained flow such as it would get using a trailblazer in uucp spoof
> mode.  It drops characters and thus uucp does lots and lots of retries.
> Dropping down to 9600 bps actually increased uucp performance in my
> tests.
> 
> This is particularly true of the console and contty ports, and is true
> of the ports board as well, but to a lesser extent.

The 3B2 has five different possibilities for serial I/O that I know of:

	console/contty		1 serial each
	PORTS			4 serial + 1 parallel
	PORTS / HPP		4 serial + 1 parallel
	EPORTS			8 serial
	fiber + expander	various combinations

The last takes just one slot and lets you put lots of ports
(up to 32 or 64 or so), but I don't know much about it so I will
defer on it.   I also am not counting any Starlan issues (if any).

All 3B2s have console and contty ports, and these ports are on the
motherboard and serviced by the main CPU (by the DUART driver).  They
can handle quite a good data rate -- sustained full 19200 bps output --
but they degrade quickly when the system gets busy.  We tell our customers
to stick a 2400bps modem on the contty port because that's a pretty slow
speed and is likely to be working even if the other serial cards go down
(so we can dial in and fix stuff).

Next is the PORTS board.  These are worthless.  In my tests, an unloaded
14MHz 3B2/310 (40% faster than standard) can only do about 6500bps output
on a raw port, so clearly 9600bps is out of the question.  Furthermore,
there is a bug in the PORTS driver where backspaces always have delays
in certain common modes.  Try this on your PORTS board:

	echo 'xxxxxxxxxxxxxxxxxxxxx\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b'

and watch it dump out the Xs very quickly and then take its time
moving the cursor back.  It can be maddening, so I "fixed" it by
define the cursor-left character in terminfo as ESC[D.  Sending
three characters is MUCH faster than waiting on the delays.

PORTS HPP is purported to be a high-performance version, but I
don't know much about it (others are welcome to chime in here).
I have heard that this was originally developed with the military
in mind, but that very well could be idle gossip.  I don't know
if it has the same backspace delay bug.

Last is EPORTS, which is a throughput monster.  It's got a smart
little 80188 or something like that, high-end Zilog serial
controllers plus DMA channels for each.  These things can do
sustained 19200bps input/output on multiple ports without
dropping a bit, and in general are very fast.

They support CTS/RTS flow control, but it is done in a way that
makes them not very helpful for many of us.  The big bug is that
CTS/RTS is mutually exclusive of XON/XOFF -- you can never run
both at the same time.  I would love to turn on HFC permanently
and tell my Telebit to always run at 19200 in locked interface
mode, and then allow dialin users to call in at (say) 2400bps and
have them flow-control down to the right speed.

Sure, the CTS/RTS works fine between the modem and the port, but
the user hitting ^S on his/her end will be ignored.  I use a
TeleVideo 9220 and I tried hooking it up to use DTR handshaking.
It worked great until I hit a ^S to stop some output.  Because
CTS/RTS was enabled, the ^S was echoed back to my terminal,
locking it up.  Wonderful.

Anyway, the design of the board also means that using XON/XOFF at
really high data rates will have significant problems.  Rather
than have each incoming character interrupt the EPORTS CPU,
instead the UART just dumps it into local RAM via the DMA
channel.  Then, at periodic intervals, the onboard CPU looks at
each input queue and transfers the data to the 3B2's I/O system.
It's quite a slick system.

The bummer is that an XOFF arriving from the other end won't be
seen right away.  Let's say that the XOFF arrives just after that
particular queue has been examined by the onboard CPU.  It will
take some amount of time before its turn comes again, and at high
data rates this time can be significant.  I'm told that "skid" of
32 or 64 characters is not uncommon, and all the HP LaserJets
that I've seen can't deal with this.  You gotta either slow it down,
use hardware flow control, or use a parallel port.

Finally, the EPORTS have had >tremendous< problems in the past
with bugs.  I have had several customers ready to throw their
computers out the window due to EPORTS problems, and only in the
last year or year and a half has it been better (with the 1.3
driver).  I understand that the EPORTS folks in Lisle had a very
miserable summer of 1988.

Whew!

     Steve

-- 
Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy
+1 714 544 6561  / friedl at mtndew.Tustin.CA.US  / {uunet,attmail}!mtndew!friedl

"I'm a simple girl; I wear a cat on my head." - Laura Dykstra @ NCR Orlando