Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mtndew!friedl From: friedl@mtndew.UUCP (Stephen J. Friedl) Newsgroups: comp.sys.att Subject: Re: 3B2/310 & TB+ Summary: everything you wanted to know about 3B2 serial hardware Keywords: Hardware Flow Message-ID: <470@mtndew.UUCP> Date: 27 Jul 90 20:53:07 GMT References: <3580@sactoh0.UUCP> <1990Jul25.062920.12777@robohack.UUCP> <16192@ucsd.Edu> Organization: VSI*FAX Tech Center Lines: 103 In article <16192@ucsd.Edu>, brian@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@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl "I'm a simple girl; I wear a cat on my head." - Laura Dykstra @ NCR Orlando