bei@puzzle.UUCP (Bob.Izenberg) (02/11/90)
I've got a Telebit T2500 on a lightly loaded (one other 2400 baud modem) eports
board, and I'm weighing the merits of hardware flow control. First off is how
to get epstty hfc to be run when both inbound and outbound uucicos are started.
Here's what I've thought of so far:
A shell script to call epstty and then uucico as nuucp's login shell
This wouldn't work for outbound calls :-(
Something off the wall, like linking a pty to the port and running
epstty against that. Is epstty smart enough to see through
this?
Give up on it, and stay with no flow control
This may be a fool's errand, since I remember what a hard time even skid-fixed
eports drivers have with buffered devices. I'm thinking of laser printers in
particular. Since there is some skid in a T2500, it might not be a good idea.
By the way... If anyone has this working, how did you change your ACU modem
adaptor? Pinouts, please.
Thanks!
-- Bob
--
------------------------------------------------------------------------------
Bob Izenberg [ ] attctc,rpp386,cs.utexas.edu!puzzle!bei
------------------------------------------------------------------------------friedl@mtndew.UUCP (Steve Friedl) (02/11/90)
In article <268@puzzle.UUCP>, bei@puzzle.UUCP (Bob.Izenberg) writes: > I've got a Telebit T2500 on a lightly loaded (one other 2400 baud modem) > eports board, and I'm weighing the merits of hardware flow control. Oh boy. I have worked a lot with EPORTS and can probably help with this. This board is much more powerful than the old PORTS board (4 serial, 1 parallel) but it has a number of real problems. They are only recently getting the driver and/or pumpware working right, so it mostly doesn't lock up. We have had customers nearly commit suicide over this, and the joke around the office then was that the EPORTS debacle in summer 1988 was the reason that Cassoni left :-). This problem is the only one that they seem to be working on. Software flow control has real trouble at high speeds. They use direct UART-to-RAM transfer via a DMA channel on the board, and it really offloads the processing on the board's and the 3B2's CPU by having no interrupts on each character. This is the good news. The problem happens when an XOFF arrives. The EPORTS 80188[?] CPU regularly scans all the input buffers looking for special characters put there by the DMA (including XOFF), but the way the board is designed means that there can be as much as a 32- character skid before output stops (my guess is if the XOFF arrives just after the input queue has been scanned). This kills an HP LaserJet at 19200bps and maybe even 9600. I have been told that this is largely unfixable. [ NOTE: the specifics of the problem described above are just what I hear on the street and have guessed at. I have never seen the code or schematics or anything. I could also be wrong on everything other than there is a very large skid. ] Hardware flow control is a mixed blessing. If you want to connect up a LaserJet via an lp interface, you cannot beat it: it is reliable and it works great. If you need it for anything else you are really out of luck. Problem #1: CTS/RTS and XON/XOFF are mutually-exclusive (!). If you want to hook up your terminal to use hardware handshake, you have to also set -ixon -ixoff -ixany or it will not work. The handshake works just fine, but if you have a habit of using ^S and ^Q for your personal flow control, it will at best not work. When you hit the ^S, it is not a special character any more so it is echoed right back to the terminal: on mine, it means "lock keyboard" Problem #2: Hardware flow control is part-time only. This means that it is reset when you close the port, so you have to actively go and turn it on all the time. Again, this is no problem if you are putting it in an lp interface, but for outgoing uucp or cu calls I have found no solution that are not horrible hardcoded hacks that no self-respecting <anybody> would ever use. These two problems make hardware flow control of very limited use, especially if you are running a telebit. For incoming uucp connections, you can in fact stick a front-end program that turns on HFC and execs the real uucico. I find it amazing that AT&T could blow it so badly on hardware flow control (especially the mutually exclusive stuff), and it means that we can only really use HFC for printers. Those of us with Telebits wanting to use them bidirectionally are really S.O.L. (especially since DTR doesn't work right on uugetty/cu anyway). If anybody has found a way to make this work right, I would love to hear about it. Steve, EPORTS old-timer P.S. - I speak for me only. Really. -- Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 voice / friedl@vsi.com / {uunet,attmail}!mtndew!friedl "Winning the Balridge Quality Award is as easy as falling off a horse." - me