NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/dec/4156

Internet Message Format | 1992-07-23 | 2.5 KB

Path: sparky!uunet!newsstand.cit.cornell.edu!vax5.cit.cornell.edu!pniy
From: [e-mail]
Newsgroups: comp.sys.dec
Subject: Single, not double precision on a 240
Message-ID: <[e-mail]>
Date: 23 Jul 92 11:19:43 EDT
Distribution: comp
Organization: Cornell University
Lines: 43

Our Decstation 5000/240 has been experiencing a bizarre problem, and
DEC is now planning to replace the CPU  board to fix it. Since DEC
was aware of this problem beforehand, but apparently not aware how
widespread the problem was, I thought I should warn people to check
for themselves.

The initial symptom was a huge program apparently running at single precision
even though we were sure it should be getting double precision answers,
and even though the same program running on other machines DID give
double precision answers. When we finally tried running the program twice
with an identical input file, we noticed that it was actually producing
output that DIFFERED from one run to another at about the 6'th or 7'th
decimal place, not good enough for our purposes. The exact same executable
file, when run on a DEC 5000/200, produced consistent results from
one run to another (also on the same input file), to all 16 places
we would expect.

Our machine was delivered at the end of May, and we have found the same
problem on another machine delivered about a month later, but it apparently
does not afflict all of the 240's, since when we communicated with the
DEC service people, they tried running the same executable over there,
and it was perfectly consistent from one run to the next, and with the
results on the 200 we tested.

I have a shorter test program that people can try on their own machines.
Please send me e-mail at:

    [e-mail]

if you are interested (NOT at the address this was posted from). This
program basically runs a series of random numbers through the sin function,
and produces consistent results about 95 % of the  time, and inconsistent
results (at the 7'th or 8'th decimal place) about 5 % of the time. However,
if you change the program slightly it becomes fully consistent (for
example, by printing things in a different order, or by rearranging
the subroutines called to generate random numbers, or by compiling
with -g instead of -O). I would also be interested in hearing who
else has had similar experiences (Dec implied there was at least somebody
out there who had noticed this before).

        Arthur Smith
        ([e-mail])