ndd@duke.uucp (12/09/84)
Recently, someone posted a request about Gould computers. I feel that the following is of general enough interest to send to the net. We have been running a PN6005 (virtual memory) computer for about 3 months now. The machine is fairly fast, the UTX/32 operating system seems to be a reasonable unixoid (SYS V + 4.1c), and the service has been pretty good, although strictly at a board swap level. Plugging boards into the back of the bus is a pain, because there are wire-wrap pins sticking out of the back-plane which are supposed to mate to sockets on the board. However, Gould puts as few sockets on the board as is possible, which causes alignment problems and not a few bent pins. BUT, the real kicker is the 8-line async interface that they provide. The original version that we received would simply not accept data from a terminal (or line to another machine) faster than 1200 baud (under UTX). The input buffer quickly overflows and loses data. So Gould brought out a new interface and driver. The new board is supposed to have bigger input buffers, but the real 'solution' is to use DTR and DSR. The new board seems to be a little faster, but it will not run even at 4800 baud without using DTR/DSR for control flow, which says to me that it really can't run at 4800 baud, period. Sure, you can set your baud rate to 4800, but the throughput is going to be way down, and what are you going to do if all your lines are 4-wire, or if the machines you talk to don't do DTR/DSR? This may not be a problem for some, or even most, sites, but I would be sure to discuss it with Gould before making a purchase. Ned Danieley Basic Arrythmia Laboratory Duke University Medical Center duke!dukebar!ndd
ron@BRL-TGR.ARPA (12/09/84)
GAK! You shold not use DSR and DTR for flow control. DTR hangs up comm gear and on my terminal at home, DSR dropping shuts down the terminal. Maybe you mean RTS and CTS? It's still pretty disgusting. If it's true, I think we better send our Gould back. -Ron
wls@astrovax.UUCP (William L. Sebok) (12/09/84)
> GAK! You shold not use DSR and DTR for flow control. DTR hangs up > comm gear and on my terminal at home, DSR dropping shuts down the > terminal. > > Maybe you mean RTS and CTS? It's still pretty disgusting. If it's > true, I think we better send our Gould back. > > -Ron Personally I think RTS and CTS flow control is less disgusting than XON and XOFF (I think XON, XOFF is disgusting). I think that flow control should have been done out-of-band whenever possible. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls
greenber@acf4.UUCP (12/10/84)
<> I'd like to see that on a three wire system (2,3 &7)!
henry@utzoo.UUCP (Henry Spencer) (12/11/84)
> Personally I think RTS and CTS flow control is less disgusting than XON and > XOFF (I think XON, XOFF is disgusting). I think that flow control should have > been done out-of-band whenever possible. XON and XOFF *are* out-of-band. They are control characters, reserved for such signalling purposes, not data characters. Re-read the ASCII standards if you don't believe me. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jbn@wdl1.UUCP (01/16/85)
In a strict interpretation of the ASCII standard, all control characters belong to the line discipline, and there should be no CTRL key on terminals. There are terminals that work this way; Univac UNISCOPE polled terminals, for example. But they are very rare today. If XON-XOFF are to be considered out-of-band signals, means must exist to prevent their use as data characters.