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!karshkeith@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
jbn@wdl1.UUCP (09/06/85)
Much of the above is all too familiar. At one time, we had one Sun, and one Masscomp. We now have sixteen Suns, and one Masscomp. John Nagle
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-relaykeith@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