karsh@geowhiz.UUCP (Bruce Karsh) (09/02/85)
We have been having lots of problems with our Masscomp systems. I would like to hear if other sites are having similar problems. Perhap somebody from Masscomp could respond to this. 1) Ethernet a) Telnet and rlogin both drop characters on long printouts. If you telnet or rlogin into another lightly loaded machine, and you do, for example, an ls -l /bin /usr/bin, you will start to get garbled lines after the first few hundred come out. The upshot of this is that users can telnet and rlogin if they don't try to look at too many lines. b) Ftp often can not transfer more than one file successfully. It gives messages about lines not being opened. The upshot of this is that users can ftp if they don't try to transfer more than 1 file at a time. c) We installed the Berkeley 4.2 talk program. It crashes the system if both talkers are sending at a high rate. The nature of the crash is rather unusual. All terminals on the system go into a state where they drop lots of characters, seemingly at random. Terminal input seems to be processed normally. At first I thought that the stty modes were screwed up. But I checked by doing a stty -a > file before I rebooted. When the machine came back up, I diff'ed file with the output of a stty -a command, and both were identical. The upshot of this is that users can use talk if they are careful to type slowly. d) The subroutine call bindings used by Masscomp are not the same as those used in BSD4.2. I don't know if they are == to anybody else's bindings. [ If they are, I don't think Masscomp says so anywhere in their manuals.] The upshot of this is that if you want to take Ethernet source from net.sources, you've got a lot of converting to do. And if you send sources out to the net, everybody else has a lot of converting to do. e) Masscomp does not support Ethernet gateways. The upshot of this is that it is hard to get onto things like ARPA-NET. f) Rlogin and telnet sometimes go into a mode where they will not accept a password. The upshot of this is that you have to login as superuser, take the machine off the net, and bring it up again. In order to do this, you throw off any existing Ethernet links to you machine. 2) Terminal I/O a) The serial ports drop characters on input, especially during uucp. You get screenfuls of buffer overrun messages and/or missed interrupt messages on the console. Masscomp claims that their serial ports are good to 2400 baud. We don't have any problems to report on serial output. The upshot of this is that you should forget about receiving serial data at sustained rates of more than 2400 baud. 3) Graphics a) The graphics terminal crashes a lot for a lot of different reasons. It is fairly easy for a user program to cause a crash. When this happens, the only way to reset the graphics terminal is to reboot the system. [Note, we have 16 termial ports hooked up to the system, spread all over our building. Rebooting it is very unpopular.] The upshot of this is that it is difficult to run a multi-user system based on Masscomps. b) The subroutine bindings for the Masscomp graphics are unusual, to say the least. Our users find them pretty hard to understand and to use. They are in no way device independent. They don't come with man pages. Some operations are slow. For example, it takes a minute and a half to blank out the screen by setting pixels to white. The built-in operations like fill box are fast though. The upshot of this is that Masscomp's graphics library is not for beginners. And it isn't very good for pixel by pixel imaging. c) We have a six plane system. We feel that we should be able to get 32 different colors on the screen at once. We can, sort of. Color map register zero is always set to black and can not be changed. So you can have any color you want there, as long as it's black. The upshot of this is that you will often have to put kluges into programs to get around the color map zero problem. d) The graphics library links in about 80K of stuff into your a.out file. The upshot of this is that graphics programs load slowly. You should also consider getting an Eagle disk to hold your graphics binaries. e) Masscomp supports the Precision Visuals graphics package. This is what they tell you to get if you complain about their graphics package. The Precision Visuals package is supposed to support device independent graphics. On other systems, it does. On Masscomps, it supports the Masscomp color display and a exactly one HP plotter. The HP plotter doesn't work with some of their extended routines. A lot of our users would like to hook up their plotter to their terminal so they can work from their offices. The upshot of this is that you don't really get device independent graphics with your Masscomp. f) The link time for graphics jobs using the Precision Visuals package is quite long. Not only does it include the Masscomp graphics libraries, but it also includes a whole bunch more. The upshot of this is that you can go eat lunch while your graphics job is compiling. (Just be sure that you have enough disk space before you go.) g) It is usually pretty fatal to suspend (i.e. ctrl-z) a graphics job. The upshot of this is that you should not suspend graphics jobs. h) The keyboard on the graphics terminal does not have auto-repeat keys. The upshot of this is that you have to hold the repeat key alot. 4) Service a) Service contracts are expensive. Expect to be charged about $10K/yr for a typical system. The upshot of this is that you are forced to choose between buying more workstations or keeping the ones you've got on service. b) Masscomp does not supply enough hardware documentation for you to maintain a system yourself. The upshot of this is that if you don't have a service contract, you should cross your fingers very firmly. c) While hardware problems are repaired pretty quickly, software problems are not fixed at all. All you can do is fill out a bug report form (unbelievably called a Software Quality Report) and hope that the problem is fixed in some later release. Often they are not. If you are having problems with software bugs, they will let you talk to a software engineer If you are covered under a software contract. The software engineer will politely tell you that you are experiencing a software problem and that you should send in a Software Quality Report. If you are not covered under a service contract, they will also let you talk to a software engineer, for $80/hr. They first ask you for a purchase order number to bill to. The upshot of this is that there are an infuriating number of software bugs in the system that never get corrected. 5) Data acquisition and control processor. a) The Data acquisition and control processor is, I think, the reason that most people buy Masscomps. The DACP crashes systems. Masscomp seems to show no interest at all in fixing DACP problems. They do include a reasonably complete, but by no means exhaustive bug list with the DACP. It is 18 pages long! It's dated November 1984! The upshot of this is that you should get practiced at rebooting the system when you develop DACP code. And you should try to think of more than one way to approach your problem so you have more options when you run into DACP bugs. 6) Source code. a) Masscomp claims that you can get source for their system. In our case, we paid $2000 and got an out of date version. We complained, and were told that we would get a new version. This has never happened. They are just about ready to bring out what they claim is a major new release of the system (Version 3). We wonder if we will see the source for our current version sometime very close to when version 3 is released. The upshot of this is that you can fix problems in the system if the source code supplied has not changed too much from the source code for the version that you are running. b) You don't get source code for the graphics processor, the serial card, or the DACP. Of course, these are some of the biggest problem areas that we have. The upshot of this is that you can't fix some of the most troubling bugs yourself. 7) Sales. a) The sales people have an infuriating habit of not returning telephone calls. This is especially annoying when you are trying to purchase things from them. We have purchased about $200,000 worth of stuff from them in the past. You would think they would be helpful when we are having problems. The upshot of this is that you should not count on you salesman to be helpful when you run into problems. -- Bruce Karsh U. Wisc. Dept. Geology and Geophysics 1215 W Dayton, Madison, WI 53706 (608) 262-1697 {ihnp4,seismo}!uwvax!geowhiz!karsh
keith@cecil.UUCP (keith gorlen) (09/03/85)
> c) We installed the Berkeley 4.2 talk program. It crashes the system > if both talkers are sending at a high rate. The nature of the crash > is rather unusual. All terminals on the system go into a state where > they drop lots of characters, seemingly at random. Terminal input > seems to be processed normally. At first I thought that the stty These symptoms sound exactly like a problem we have been having on our system recently (running RTU V2.1) -- but we do not have the Berkeley 4.2 talk program, or even Ethernet (yet). -- Keith Gorlen seismo!elsie!cecil!keith
charliep@polaris.UUCP (Charlie Perkins) (09/11/85)
I read with great interest Bruce Karsh's complaint regarding Masscomp's Unix systems. I have a great deal of experience in dealing with Masscomp, so I thought I would add a few words to this discussion. Under no imaginable circumstance should my statements be regarded as related in any way to IBM policies, strategies, plans, or anything official at all! (there, is THAT strong enough??). First of all, I was surprised to read that there had been trouble getting phone calls returned from Masscomp sales people. For me, it has been exactly the opposite. Masscomp sales has been unfailingly considerate and diligent. I have even found that the sales people know something about the technical details of their computers, although not enough. I keep getting the impression that they want to sell me more computers and that if they return calls and describe upcoming products they will have a better chance of doing so. We have had many, many problems with our equipment here. The most prominent problem (and it has been a super headache) has been the Ethernet card used by Masscomp, made by Excelan. This card (in my opinion a poor choice since, using it, Masscomp cannot be a network gateway) has recently been found by Excelan to have (other) design problems. I am told that when the redesign is finished, we will be getting more reliable cards as needed. And, it is about time. I have noticed the other problems that Bruce mentions, but only rarely. Ethernet data is never lost going into a file, only when it is to be displayed by the window manager. Other problems have included power supplies, flaky graphics cards, and interrupt problems resulting from not following certain guidelines which were never documented. They are all fixed now. I really have to compliment Masscomp service. In our many dealings with the service organization, I have been usually satisfied with their response time and effectiveness, and have always been satisfied with their courtesy. My major complaint is the length of time it took to figure out the Ethernet problems. There have been a few other problems. For me it has been very frustrating not to have source, because our entire department relies heavily on the use of the network, and I just want to go fix things when they don't work. The service we have received for software problems has been much more uneven than for hardware, but still generally acceptable. I will not comment on the use of the Graphics libraries. I like the use of the window manager that comes with it, but there are some incredible bugs. Trying to suspend the C-shell you get with a new window will hang up the entire window manager (including mouse and keyboard!). As superuser you can send CONT signals to the affected processes but the window manager never completely recovers. I am hoping that the newer release of the graphics products will be much better (rumored for later this year). All in all the window manager is a nice feature to have, but implemented poorly. Masscomp provides an ambitious array of features. They do have bugs, but they are serious about getting them out, and things are getting better (around here, at least). They have good performance for floating point computations and good overall performance. I will be finding out lots more about the graphics side of things later this year... However, I think that they have little competition when it comes to gathering data onto disk in real time (at least, in the Unix marketplace). I would be interested in hearing about competitive products if there are any. In summary, I will say that our Masscomp systems have been an effective computing medium for our needs. There have been lots of technical problems, but not many people problems. I could go on with choice tidbits about specific bugs, but I am sure every computer manufacturer has these. Don't get me started about the Vaxes I used to work with! And, finally, in my opinion there are a lot of competent engineers working at Masscomp who intend to fix problems as they are found -- as well as continually upgrading and adding needed features. That has to count for a lot. Charlie Perkins, IBM T.J. Watson Research philabs!polaris!charliep, perk%YKTVMX.BITNET@berkeley, perk.yktvmx.ibm@csnet-relay PS. Masscomp, are you listening?? When are you going to implement bug submission via electronic mail??? How about tomorrow? -- Charlie Perkins, IBM T.J. Watson Research philabs!polaris!charliep, perk%YKTVMX.BITNET@berkeley, perk.yktvmx.ibm@csnet-relay
keith@cecil.UUCP (keith gorlen) (09/12/85)
My experience with Masscomp has been similar to that of Charlie Perkins. We have had our system for two years, and have had very few hardware problems; when we do have a problem it is promptly fixed. As a result, system availability is about 99%. There are software problems, but telephone support has been good. On several occasions the person who wrote the code has spent hours on the phone to get a problem resolved. Overall, I think the Masscomp has excellent data acquisition and scientific data processing capabilities combined with mediocre graphics. Hopefully the graphics will be better on their soon-to-be announced new product line. (The above opinions are my own, obviously!) -- Keith Gorlen seismo!elsie!cecil!keith