My Perspective on the Pentium Processor - ASG
Andy Grove
of Intel. We want to make sure this gets broadly distributed amongst the
Internet users.
This is Andy Grove, president of Intel. I'd like to comment a bit on
the conversations that have been taking place here.
First of all, I am truly sorry for the anxiety created among you by
our floating point issue. I read thru some of the postings and it's
clear that many of you have done a lot of work around it and
that some of you are very angry at us.
Let me give you my perspective on what has happened here.
The Pentium processor was introduced into the market in May of '93
after the most extensive testing program we at Intel have ever
embarked on. Because this chip is three times as complex as the 486,
and because it includes a number of improved floating point
algorithms, we geared up to do an array of tests, validation, and
verification that far exceeded anything we had ever done. So did many
of our OEM customers. We held the introduction of the chip several
months in order to give them more time to check out the chip and their
systems. We worked extensively with many software companies to this
end as well.
We were very pleased with the result. We ramped the processor faster
than any other in our history and encountered no significant problems
in the user community. Not that the chip was perfect; no chip ever
is. From time to time, we gathered up what problems we found and put
into production a new "stepping" -- a new set of masks that
incorporated whatever we corrected. Stepping N was better than
stepping N minus 1, which was better than stepping N minus 2. After
almost 25 years in the microprocessor business, I have come to the the
conclusion that no microprocessor is ever perfect; they just come
closer to perfection with each stepping. In the life of a typical
microprocessor, we go thru half a dozen or more such steppings.
Then, in the summer of '94, in the process of further testing (which
continued thru all this time and continues today), we came upon the
floating point error. We were puzzled as to why neither we nor anyone
else had encountered this earlier. We started a separate project,
including mathematicians and scientists who work for us in areas other
than the Pentium processor group to examine the nature of the problem
and its impact.
This group concluded after months of work that (1) an error is only
likely to occur at a frequency of the order of once in nine billion
random floating point divides, and that (2) this many divides in all
the programs they evaluated (which included many scientific
programs) would require elapsed times of use that would be longer than
the mean time to failure of the physical computer subsystems. In
other words, the error rate a user might see due to the floating point
problem would be swamped by other known computer failure mechanisms.
This explained why nobody -- not us, not our OEM customers, not the
software vendors we worked with and not the many individual users --
had run into it.
As some of you may recall, we had encountered thornier problems with
early versions of the 386 and 486, so we breathed a sigh of relief
that with the Pentium processor we had found what turned out to be a
problem of far lesser magnitude. We then incorporated the fix into
the next stepping of both the 60 and 66 and the 75/90/100 MHz Pentium
processor along with whatever else we were correcting in that next
stepping.
Then, last month Professor Nicely posted his observations about this
problem and the hubbub started. Interestingly, I understand from
press reports that Prof. Nicely was attempting to show that
Pentium-based computers can do the jobs of big time supercomputers in
numbers analyses. Many of you who posted comments are evidently also
involved in pretty heavy duty mathematical work.
That gets us to the present time and what we do about all this.
We would like to find all users of the Pentium processor who are
engaged in work involving heavy duty scientific/floating point
calculations and resolve their problem in the most appropriate fashion
including, if necessary, by replacing their chips with new ones. We
don't know how to set precise rules on this so we decided to do it
thru individual discussions between each of you and a technically
trained Intel person. We set up 800# lines for that purpose. It is
going to take us time to work thru the calls we are getting, but we
will work thru them. I would like to ask for your patience here.
Meanwhile, please don't be concerned that the passing of time will
deprive you of the opportunity to get your problem resolved -- we
will stand behind these chips for the life of your computer.
Sorry to be so long-winded -- and again please accept my apologies
for the situation. We appreciate your interest in the Pentium
processor, and we remain dedicated to bringing it as close to
perfection as possible.
I will monitor your communications in the future -- forgive me if I
can't answer each of you individually.
Andy Grove
Larry Lefkowitz
: We are making a second posting of the previous posting made by Richard Wirt
: of Intel. We want to make sure this gets broadly distributed amongst the
: Internet users.
I appreciate your response to this problem, and consider it a fair and
equitable response. I am doing some work related to aircraft in which
accuracy is critical, and was quite concerned about Intels response.
Your response has earned my respect and future business.
Larry Lefkowitz
Scott R. Eliason
Larry Lefkowitz writes:
That's nice that that posting earned your respect. I have two questions
though. First, do you have a buggy Pentium chip? And if so, did Intel
promise to replace it?
Scott R. Eliason (scott-eliason)
Department of Sociology
University of Iowa
()
larr...@anshar.shadow.net (Larry Lefkowitz) wrote:
Sucker!
In all seriousness, that b.s. statement was very possibly written by
lawyers who thought that having Grove post it as something he actually
wrote would appease the masses. Even if he did write it, it's obviously
nothing more than attempt to salvage what's left of Intel's reputation
on the Internet.
The thing to base your respect and future business on is Intel's actual
reaction to the problem, not what the president or others say to calm
people down (i.e. Actions speak louder than words).
FWIW, that statement made Intel look even worse IMO... I'll never buy
another Intel product again...
-radix (who would've bought his Pentium last week, but got an
AMD chip instead...)
UTexas College of Pharmacy - Austin, Texas
(sik...@axpvms.cc.utexas.edu) (all statements are only my opinions...)
Jon Jenkins
: We are making a second posting of the previous posting made by Richard Wirt
ryan
>
>Meanwhile, please don't be concerned that the passing of time will
>deprive you of the opportunity to get your problem resolved -- we
>will stand behind these chips for the life of your computer.
Stand behind these chips? Looks to me like your hiding. What a load of crap.
It really pisses me off that I paid good money for this chip. But because I don't
do math-intensive work for some big company who probably got their pentiums
wholesale, I am dirt.
>Sorry to be so long-winded -- and again please accept my apologies
>for the situation. We appreciate your interest in the Pentium
>processor, and we remain dedicated to bringing it as close to
>perfection as possible.
But for those of you who were involved in our beta test of the chip, tough luck.
>I will monitor your communications in the future -- forgive me if I
>can't answer each of you individually.
Yeah, monitor this.
ryan shaw
rys...@xmission.com snow, snow, snow, snow, snow, snow.
http://www.xmission.com/~ryshaw
"Pass the salt, pour it in my wounds." -Quicksand
Jon Jenkins
a doubt as I cannot finger you or ping the news server
and mail to the sender bounces. However, I will assume
it is for the moment.
Mr Grove,
At the risk of some considerable flak I would like firstly
to thank you for your presence here and secondly to reply to some
of your comments. To fill in a little details, I purchased my Pentium
about 6 weeks ago for a specific purpose: to port a microwave circuit
simulation package to WIndows NT and Windows 95. It was a
considered purchase because I thought that the PC had finally enough
grunt for what had previously been workstation teritory. After some
teething problems with BIOS versions and SCSI problems I finally got
the system up and running. I recompiled the DOS/Windows version of
the code base and started running the benchmark ciruit and exercisers
with good results. However, there were a few concerns: some results
were outside the expected variances when compared to other platforms
(Alpha, 486, SUN) and two results in particular were significantly
different. I naturally suspected some sw problems and after a few
days started to track them down. After several weeks of looking
I could find no sw reason for the differences. It was then that I
saw a single posting by Terje Mathisen outlining a post by Professor
Nicely and a reference to a FDIV bug in the Pentium. I replied
immediately confirming that I had seen this anomaly and that it
was not a compiler error. After a tedious exercise I was
able to determine that the error was caused by a faulty divide
when a filter coefficient was used at a particular frequency.
So now I have a Pentium machine which is useless for its intended
purpose because I do not know when or with what magnitude this
bug will appear.
Andy Grove (Andy_...@intel.com) wrote:
: We are making a second posting of the previous posting made by Richard Wirt
: of Intel. We want to make sure this gets broadly distributed amongst the
: Internet users.
: This is Andy Grove, president of Intel. I'd like to comment a bit on
: the conversations that have been taking place here.
:
: First of all, I am truly sorry for the anxiety created among you by
: our floating point issue. I read thru some of the postings and it's
: clear that many of you have done a lot of work around it and
: that some of you are very angry at us.
Angry does not begin to describe the feeling of many scientists
and engineers I have spoken to. Furious, outraged are more
approriate terms. Many of them will have to redo/check many
months of work and have spent money on Pentiums that are useless
for their intended task. But most of all they feel betrayed
that Intel would knowingly and secretly continue to distribute
computers which although purported for high end high precision
applications are useless for that task.
:
: Let me give you my perspective on what has happened here.
:
: The Pentium processor was introduced into the market in May of '93
: after the most extensive testing program we at Intel have ever
: embarked on. Because this chip is three times as complex as the 486,
: and because it includes a number of improved floating point
: algorithms, we geared up to do an array of tests, validation, and
: verification that far exceeded anything we had ever done. So did many
: of our OEM customers. We held the introduction of the chip several
: months in order to give them more time to check out the chip and their
: systems. We worked extensively with many software companies to this
: end as well.
:
: We were very pleased with the result. We ramped the processor faster
: than any other in our history and encountered no significant problems
: in the user community. Not that the chip was perfect; no chip ever
: is. From time to time, we gathered up what problems we found and put
: into production a new "stepping" -- a new set of masks that
: incorporated whatever we corrected. Stepping N was better than
: stepping N minus 1, which was better than stepping N minus 2. After
: almost 25 years in the microprocessor business, I have come to the the
: conclusion that no microprocessor is ever perfect; they just come
: closer to perfection with each stepping. In the life of a typical
: microprocessor, we go thru half a dozen or more such steppings.
You assume that the processor is suitable and usable for its intended
task. No scientist or engineer who uses extended floating point
applications could use a Pentium for their work now. Leaving alone
any legal ramifications from producing erroneous results (however
small the probability) it is unethical to use a known faulty system
and the overhead of checking the results by hand renders its useless.
Basically they will be used as "fast" word processors until the
new "fixed" chips are generally available.
:
: Then, in the summer of '94, in the process of further testing (which
: continued thru all this time and continues today), we came upon the
: floating point error. We were puzzled as to why neither we nor anyone
: else had encountered this earlier. We started a separate project,
: including mathematicians and scientists who work for us in areas other
: than the Pentium processor group to examine the nature of the problem
: and its impact.
As posted here in this newsgroup, a simple linear search will turn up
1-2 errors per hour. This does not require a PhD to see that if 1 box
will produce this many erros that 2.5 million boxes will produce
a proportionally large number of errors.
:
: This group concluded after months of work that (1) an error is only
: likely to occur at a frequency of the order of once in nine billion
: random floating point divides, and that (2) this many divides in all
: the programs they evaluated (which included many scientific
: programs) would require elapsed times of use that would be longer than
: the mean time to failure of the physical computer subsystems. In
: other words, the error rate a user might see due to the floating point
: problem would be swamped by other known computer failure mechanisms.
: This explained why nobody -- not us, not our OEM customers, not the
: software vendors we worked with and not the many individual users --
: had run into it.
As I said a simple linear search will turn up 1-2 errors per hour. But
that is not the point. What are the two points:
1: As soon as you/Intel knew about this the scientific and engineering
community i.e those most affected, should have been informed.
You/Intel have a moral and possibly a legal requirement to do this.
2: As also described in this group, with the number of chips out
there and some quick estimates that 4-5 people will encounter
errors per day. I suspect most of these errors will be insignificant
but occasionally they will be of a larger magnitude.
:
: As some of you may recall, we had encountered thornier problems with
: early versions of the 386 and 486, so we breathed a sigh of relief
: that with the Pentium processor we had found what turned out to be a
: problem of far lesser magnitude. We then incorporated the fix into
: the next stepping of both the 60 and 66 and the 75/90/100 MHz Pentium
: processor along with whatever else we were correcting in that next
: stepping.
:
: Then, last month Professor Nicely posted his observations about this
: problem and the hubbub started. Interestingly, I understand from
: press reports that Prof. Nicely was attempting to show that
: Pentium-based computers can do the jobs of big time supercomputers in
: numbers analyses. Many of you who posted comments are evidently also
: involved in pretty heavy duty mathematical work.
As I said above it appeared that the PC had finally "come of age"
However, that is now obviously not the case. No scientist or engineer
could knowingly use a Pentium just in case the bug showed up,
however small the probability.
:
: That gets us to the present time and what we do about all this.
:
: We would like to find all users of the Pentium processor who are
: engaged in work involving heavy duty scientific/floating point
: calculations and resolve their problem in the most appropriate fashion
: including, if necessary, by replacing their chips with new ones. We
: don't know how to set precise rules on this so we decided to do it
: thru individual discussions between each of you and a technically
: trained Intel person. We set up 800# lines for that purpose. It is
: going to take us time to work thru the calls we are getting, but we
: will work thru them. I would like to ask for your patience here.
This is appreciated and expected from Intel. I uunderstand
that Intel could not possibly replace All pentiums instantly
or inthe near future. I also understand that a significant
proportion of users will never use the FPU for their games
or word processing. However note that even simple integer
arithmetic can produce significant errors if the underlying sw
uses extended floating point. Ther have been
several examples of, agreeably contrived but none the less, plausible
problems with financial calcualations posted to this group.
What of the people who are refused new chips ? If Intel
decides not to replace the chip will there be an independant
appeals panel to reassess the request ?
:
: Meanwhile, please don't be concerned that the passing of time will
: deprive you of the opportunity to get your problem resolved -- we
: will stand behind these chips for the life of your computer.
If you are going to "play" in the workstation market then this
is expected behaviour. It is still possible to get support
for 10 year old work stations from all the major vendors
and if Intel want to sell in this market then they will have
to act likewise. In fact I suspect that this is why there
is such a reaction to this "issue" in the Internet community
because the majority of users are more accustomed to
dealing with SUN, DEC, IBM, SGI who probably because
of the much lower numbers of boxes and direct market
access, would almost certainly replace CPUs without
question. As I said I understand why this might not
be possible and not required in this case.
:
: Sorry to be so long-winded -- and again please accept my apologies
: for the situation. We appreciate your interest in the Pentium
: processor, and we remain dedicated to bringing it as close to
: perfection as possible.
:
: I will monitor your communications in the future -- forgive me if I
: can't answer each of you individually.
: Andy Grove
What is needed now apart from anything else is a complete
technical description of the bug. You/Intel must have
this information at your disposal and could easily
release it. This would allow the less hysterical
at least to make an assessment of the problem and
its possible effect on their work. It may also
aid immeasurably in design and implementation
of any potential workarounds and sw fixes for those
not deemed suitable for replacement.
As a closing and personal remark, the aspect of this
which most annoys me is not that I may have to pay
for a new CPU although I probably will after this posting ;-),
as I would treat that in the same vein as a sw
upgrade, claim it on next years tax return and forget
it. What really irks me is Intel's failure to inform
me of a problem which WILL affect the intended use
for my Pentium. Sureley, just like sw (hw is really
just sw on silicon) a regular and honest bug list is
an essential part of doing buisness in the high
end market.
Regards,
Jon Jenkins
----------------------------------------------------------------------
Name: Dr Jon Jenkins
Location: Digital Equipment Corp, NaC,
Burnett Place, Research Park,
Bond University, Gold Coast
QLD, AUSTRALIA 4229
Phone: 61-75-75-0151
Fax: 61-75-75-0100
Internet: jenk...@ozy.dec.com
The opinions expressed above are entirely personal and do not
reflect the corporate policy of DEC or the opinions of DEC management.
-----------------------------------------------------------------------
Alan L. Cassel
: I appreciate your response to this problem, and consider it a fair and
: accuracy is critical, and was quite concerned about Intels response.
: Your response has earned my respect and future business.
For future reference, could you please tell us what aircraft companies you
work with, and exactly what kind of work you do?
JAMES STOLIN
>I appreciate your response to this problem, and consider it a fair and
>equitable response. I am doing some work related to aircraft in which
>accuracy is critical, and was quite concerned about Intels response.
Larry,
Fair and equitable? Have your critical aircraft calculations been done
with a faulty Pentuim? If so, please let us know what aircraft you have
done calculations for so we can avoid or at least be aware of these in
the future. Thank you.
-
James B. Stolin - Illinois Computer Service - FKN...@prodigy.com
JAMES STOLIN
it is returned message.
|--------------- CC:MAIL GATEWAY ERROR MESSAGE FOLLOWS: ---------------
|
'andy_i...@ccm.sc.intel.com' is not in the gateway's cc:Mail directory.
There were no valid cc:Mail addresses to deliver this message to.
|--------------------- ORIGINAL MESSAGE FOLLOWS: ----------------------
|
Received: from relay.jf.intel.com by relay.hf.intel.com with smtp
(Smail3.1.28.1 #2) id m0rCOVG-000qDKC; Tue, 29 Nov 94 01:05 PST
Received: from hermes.intel.com by relay.jf.intel.com with smtp
(Smail3.1.28.1 #2) id m0rCOVG-000twdC; Tue, 29 Nov 94 01:05 PST
Received: from aurora.intel.com by hermes.intel.com (5.65/10.0i); Mon,
28
Nov 94 17:24:51 -0800
Received: from inetgate.prodigy.com by aurora.intel.com (5.65/10.0i);
Mon,
28 Nov 94 17:24:06 -0800
Received: from mail.prodigy.com by inetgate.prodigy.com with SMTP id
AA60121
(5.65c/IDA-1.4.4 for <ANDY_...@INTEL.COM>); Mon, 28 Nov 1994 20:05:26
-0500
Date: Mon, 28 Nov 1994 20:05:43 EST
From: FKN...@prodigy.com (MR JAMES B STOLIN)
X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-308.52]
Message-Id: <013.019826...@prodigy.com>
To: ANDY_...@INTEL.COM
Subject: Perspective on your Pentium Perspective
Andy,
At first, I was goping to reply to you publicly regarding your
"Pentium perspective" Internet post. However, I thought a private
feedback to you would perhaps serve better. Perhaps you do not
realize that your letter only made things worse.
>This is Andy Grove, president of Intel. I'd like to comment a bit
on
>the conversations that have been taking place here.
>
>First of all, I am truly sorry for the anxiety created among you by
>our floating point issue.
In the computing community, errors are commonly refered to as
"bugs". Refering to an error as an "issue" will only inflame the
already heated atmosphere regarding the Pentium FDIV problem. It
would be better to refer to it as an error, bug, mistake or similar
description. That's what it is. Calling it an issue makes customers
think you are blowing company policy marketing smoke.
>Then, in the summer of '94, in the process of further testing (which
>continued thru all this time and continues today), we came upon the
>floating point error. We were puzzled as to why neither we nor anyone
>else had encountered this earlier. We started a separate project,
>including mathematicians and scientists who work for us in areas other
>than the Pentium processor group to examine the nature of the problem
>and its impact.
The nature of the problem is that the exact impact of the FDIV
bug is unknown. Until calculations are checked on non-Pentuim
machines, the true extent of the problem will not be known. No
problems may have sufrfaced since people were taking the results from
the Pentiums as correct. Meanwhile, anyone that has used a Pentium
in mission critical work will have to redo the calculations. Only
time will tell.
>We would like to find all users of the Pentium processor who are
>engaged in work involving heavy duty scientific/floating point
>calculations and resolve their problem in the most appropriate
fashion
>including, if necessary, by replacing their chips with new ones.
It will not take heavy number crunching for a serious problem to
develop. Try telling the bank officer that miscalculates a mortgage,
gets sued or charged criminally that this is just an issue for heavy
duty scientific/floating point calculations. My $2000 Pentium
machine HAS to be at least as accurate as my $2 calculator.
Anything less and you can't do accounting or anything alse.
How about a Pentium used in process control? The vision of a
chemical plant going BANG because 256 was returned instead of a 1 or
zero is something to think about. I will agree that this is perhaps
a worse case situation but there are others just as bad. Pentiums are
used in engineering. What is Boeings next plane crashes due to a
Pentium error? The list goes on and on.
Well, I think that sums up some of the anger you are seeing. I
hope you realize that a CPU you can't trust is worse than no CPU at
all for any serious work. I would consider a Pentium with the bug
for games, a file server or anything that does not call for
calculations but that is it.
Larry Lefkowitz
: In article <3beahv$o...@anshar.shadow.net>, larr...@anshar.shadow.net
: Larry Lefkowitz writes:
Scott,
Yes, I do have a buggy Gateway P5-90 system. No, I have not yet had the
time to call the posted number, but I am assuming they *will* replace the
chip because of how I use it. If they do not replace it, that will
probably be another story.
I see all the flames here about Mr Groves response, but I felt it was a
fair one as long as they do solve the problems to the customers
satisfaction. I guess that still remains to be seen.
Larry
Larry Lefkowitz
: larr...@anshar.shadow.net (Larry Lefkowitz) writes:
: Larry,
James,
My aircraft calculations have nothing to do with aircraft design. All
are now in the process of being redone on a 486 system. I will post here
if discrpencies show up.
Larry
Larry Lefkowitz
: In article <3beahv$o...@anshar.shadow.net>,
: larr...@anshar.shadow.net (Larry Lefkowitz) wrote:
: > Andy Grove (Andy_...@intel.com) wrote:
: > : We are making a second posting of the previous posting made by Richard Wirt
: > : of Intel. We want to make sure this gets broadly distributed amongst the
: > : Internet users.
: >
: > I appreciate your response to this problem, and consider it a fair and
: > equitable response. I am doing some work related to aircraft in which
: > accuracy is critical, and was quite concerned about Intels response.
: >
: > Your response has earned my respect and future business.
: Sucker!
You are of course entitled to your own opinion. I feel this is a fair
response, including the fact that there is no time limit, so if you
change the use of your machine you can still get a fix. If Intel
satisfies the users who feel they need the fix then that will be good. If
not, of gives people a hard time, then I would change my opinion.
Larry
Larry Lefkowitz
I do not work for an aircraft company. I am an employee of the Allstate
Insurance Company. The calculations, however, are being performed in a
project unrelated to my work with Allstate.
BTW, the opinions expressed by me in no way reflect the policies or
opinions of my employer.
Larry
Tom Barrett
Andy Grove <Andy_...@intel.com> wrote:
>Meanwhile, please don't be concerned that the passing of time will
>deprive you of the opportunity to get your problem resolved -- we
>will stand behind these chips for the life of your computer.
That's all the guarantee that I wanted to hear... thanks for making
it! Time will tell who is right about how often the problem will
occur in real-life.
Regards,
Tom
--
** Tom Barrett ** tom.b...@virginia.edu
url: http://fulton.seas.virginia.edu/~tdb8q/ [updated 28 Nov 94]
Bill Seward
>
>In article <3beahv$o...@anshar.shadow.net>, larr...@anshar.shadow.net
>Larry Lefkowitz writes:
>
<Andy Grove twaddle deleted>
>>I appreciate your response to this problem, and consider it a fair and
>>equitable response. I am doing some work related to aircraft in which
>>accuracy is critical, and was quite concerned about Intels response.
< some deleted>
>That's nice that that posting earned your respect. I have two questions
>though. First, do you have a buggy Pentium chip? And if so, did Intel
>promise to replace it?
I have a third question: what aircraft have you worked on using the
Pentium machine? I want to avoid them.
-------------------------------------------
Bill Seward
w...@infi.net
I speak for myself. No one else will.
Bill Seward
<stuff deleted>
>Yes, I do have a buggy Gateway P5-90 system. No, I have not yet had the
>time to call the posted number, but I am assuming they *will* replace the
>chip because of how I use it. If they do not replace it, that will
>probably be another story.
>
Well, from what either PC Week or Infoworld published this week, get your
other story going. I wish I could provide the exact citation, but what I
read is that Gateway is telling customers to call Intel.
Another vendor I can cross my list.
-----------------------------------------------------
Larry Lefkowitz
: <stuff deleted>
You are correct. Just visited the Gateway forum on CompuServe, and they
are telling people to go to Intel directly.
I must say I am much more disturbed with Gateway than I am with Intel. I
did buy the system with them, but have a very hard time with their
attitude. First there was a problem with the serial ports, which still
persists, I must say. This is traceable to a faulty SMC chip on the Intel
produced motherboard. Even though I still experience this problem,
Gateway will not replace with a corrected motherboard. Now they are
passing the problem for the chip back to Intel and not taking any
responsibility for it. While I generally like the system I am using, I
will never buy anything else from Gateway. In all fairness, for the run
of the mill kind of tech support, their people do make a good effort, if
you are lucky enough to get through to them on the phone.
I must say it has been a rather frustrating experience being on the
bleeding edge of this new Pentium technology. I am willing to have some
patience with the vendors to allow them to get it right. What galls me is
when a company like Gateway will not correct my problem when the
corrected technology becomes available.
Larry
Sinan Karasu
>of Intel. We want to make sure this gets broadly distributed amongst the
>Internet users.
>
>
>This is Andy Grove, president of Intel. I'd like to comment a bit on
>the conversations that have been taking place here.
>
>
>Meanwhile, please don't be concerned that the passing of time will
>deprive you of the opportunity to get your problem resolved -- we
>will stand behind these chips for the life of your computer.
Mr Grove. This seems to indicate that Intel will take responsibility
for consequential damages in Washington State, since you have
acknowledged the problem, yet have not offered an immediate
solution, thus forcing users to use their defective chips
until they can prove to you that they are affected by the bug.
Is this true?
Sinan
Ahmed Naas
In article <3bb5bv$q...@inewssc.intel.com> you wrote:
:
: Meanwhile, please don't be concerned that the passing of time will
: deprive you of the opportunity to get your problem resolved -- we
: will stand behind these chips for the life of your computer.
:
Will you refund the difference when my friend sells his identical P5
machine without the FDIV bug for x dollars and I can only sell mine
for x-300 dollars? Or do you expect me to absorb the loss on behalf
of iNTEL?
: Sorry to be so long-winded -- and again please accept my apologies
: for the situation. We appreciate your interest in the Pentium
Apologies don't make up for the fact that I feel swindled. You knew
something about your product that would've affected my buying decision
and you kept it secret from me. HOW MANY OF THESE DEFECTIVE PENTIUMS
DO YOU THINK YOU WOULD'VE SOLD HAD YOUR CUSTOMERS KNOWN ABOUT THE BUG!
The only ethical course for you to take is to replace the chips on
demand and not subject your customers to the indignities they have
to go through now in order to get a replacement.
Best regards,
--
The above is a result of random neuron activity in the writer's brain.
Ahmed M. Naas ah...@oea.xs4all.nl
----------------------------------------------------------------------
Trangdaithi Hoang
>of Intel. We want to make sure this gets broadly distributed amongst the
>Internet users.
>
>This is Andy Grove, president of Intel. I'd like to comment a bit on
>the conversations that have been taking place here.
>
>
>This group [Intel QA] concluded after months of work that (1) an error
>is only likely to occur at a frequency of the order of once in nine
>
>Andy Grove
Thank you, Mr. Grove, for pointing out the severity and frequency of the
bug. Allow me to clarify what you've just said in a way most people
can understand.
The frequency of the bug, as you claim, is once in nine billion
floating point divides. According to the Intel Pentium reference
one FDIV floating point divide takes 39 cycles. A 90 MHz Pentium
running at 90,000,000 cycles per second can execute roughly
2,307,692 FDIV floating point divides per second (90,000,000 / 39).
Therefore, an error will occur at a frequency of about ONCE EVERY
3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
Pentium. The frequency of the error increases as the speed of the
Pentium increases. A Pentium 100 MHz will encounter the error
with a frequency of about ONCE EVERY 3510 SECONDS OR 58.5 MINUTES.
Now we get it! When Intel claims "an error occurs once in nine
billion floating point divides" means an error about once every
hour. Let's spread the news everyone.
BukAK!!
Mini-FAQ
--------
- discussions about the bug can be found on comp.sys.intel
- information and programs to detect the bug can also be found at the
following ftp sites:
ftp.mathworks.com in //pub/tech-support/moler/pentium
math.ucdavis.edu in //pub/fdiv
- Intel can be reached at 1-800-628-8686
Don't believe them when they try to say that the bug doesn't affect
you.
Don't accept a software patch/workaround as a permanent fix
Software is slow compared to hardware. You paid a premium for fast
hardware and not for software patch that slowly works around fast
hardware.
- you have a faulty product. They have no right to the confidentiality
of your work. Demand a replacement without questions asked.
- Spread the information and englighten your neighbors so they won't get
rippped off by Intel.
Michael Scheele
: First of all, I am truly sorry for the anxiety created among you by
: clear that many of you have done a lot of work around it and
: that some of you are very angry at us.
The discovery of the bug has undermined my confidence in the accuracy of
my recently purchased Pentium-90 system. My HP 19BII exhibits greater
accuracy than my Pentium system... I didn't check it against my HP 15C,
but I am sure it too displays better accuracy.
: Then, in the summer of '94, in the process of further testing (which
: continued thru all this time and continues today), we came upon the
: floating point error. We were puzzled as to why neither we nor anyone
: else had encountered this earlier. We started a separate project,
: including mathematicians and scientists who work for us in areas other
: than the Pentium processor group to examine the nature of the problem
: and its impact.
Many people on this newsgroup (comp.sys.intel) have posted various test
cases, most of which are very simple to reproduce.
: This group concluded after months of work that (1) an error is only
: likely to occur at a frequency of the order of once in nine billion
: random floating point divides, and that (2) this many divides in all
: the programs they evaluated (which included many scientific
: programs) would require elapsed times of use that would be longer than
: the mean time to failure of the physical computer subsystems. In
: other words, the error rate a user might see due to the floating point
: problem would be swamped by other known computer failure mechanisms.
: This explained why nobody -- not us, not our OEM customers, not the
: software vendors we worked with and not the many individual users --
: had run into it.
Some people performing rendering or using 3-d packages may encounter
these problems sooner. Given Intel's push for Pentiums for multimedia,
one would think this would be of concern.
: As some of you may recall, we had encountered thornier problems with
: early versions of the 386 and 486, so we breathed a sigh of relief
: that with the Pentium processor we had found what turned out to be a
: problem of far lesser magnitude. We then incorporated the fix into
: the next stepping of both the 60 and 66 and the 75/90/100 MHz Pentium
: processor along with whatever else we were correcting in that next
: stepping.
This is of little consolation to people affected by the defect to date.
Mistakes do happen; how you handle them is a different matter.
: We would like to find all users of the Pentium processor who are
: engaged in work involving heavy duty scientific/floating point
: calculations and resolve their problem in the most appropriate fashion
: including, if necessary, by replacing their chips with new ones. We
: don't know how to set precise rules on this so we decided to do it
: thru individual discussions between each of you and a technically
: trained Intel person. We set up 800# lines for that purpose. It is
: going to take us time to work thru the calls we are getting, but we
: will work thru them. I would like to ask for your patience here.
I will be calling...
: Meanwhile, please don't be concerned that the passing of time will
: deprive you of the opportunity to get your problem resolved -- we
: will stand behind these chips for the life of your computer.
If you are serious about this, I expect this problem to be a minor matter
in the long run. I do appreciate the balance between tangible cost and
intangible goodwill (and lost future sales) is a challenging one.
Looking forward to an amicable resolution.
Michael Scheele
Marketing Consultant (Multimedia and Interactive Technologies)
Kirkland, WA
msch...@cyberquest.com
emb121
tho...@orion.oac.uci.edu (Trangdaithi Hoang) writes:
> The frequency of the bug, as you claim, is once in nine billion
> floating point divides. According to the Intel Pentium reference
> one FDIV floating point divide takes 39 cycles. A 90 MHz Pentium
> running at 90,000,000 cycles per second can execute roughly
> 2,307,692 FDIV floating point divides per second (90,000,000 / 39).
> Therefore, an error will occur at a frequency of about ONCE EVERY
> 3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
> Pentium. The frequency of the error increases as the speed of the
> Pentium increases. A Pentium 100 MHz will encounter the error
> with a frequency of about ONCE EVERY 3510 SECONDS OR 58.5 MINUTES.
That is, of course, if your Pentium does nothing other than call FDIV.
If your programs don't call FDIV (which they won't if they're not doing
floating point math) then you'll never see the bug at all.
-Eric Bennett (er...@psu.edu)
Drawing on my fine command of the language, I said nothing.
-Robert Benchley
Brian Gross
: The frequency of the bug, as you claim, is once in nine billion
: floating point divides. According to the Intel Pentium reference
: one FDIV floating point divide takes 39 cycles. A 90 MHz Pentium
: running at 90,000,000 cycles per second can execute roughly
: 2,307,692 FDIV floating point divides per second (90,000,000 / 39).
: Therefore, an error will occur at a frequency of about ONCE EVERY
: 3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
: Pentium. The frequency of the error increases as the speed of the
: Pentium increases. A Pentium 100 MHz will encounter the error
: with a frequency of about ONCE EVERY 3510 SECONDS OR 58.5 MINUTES.
This is, of course, the case of a program which is doing nothing
but one FDIV after another and is the worst case.
I'm attempting not to enter the debate here so please take this as
just an engineer's observation.
Mr. Grove did address the FDIV frequency by essentially stating
that in a typical program (including "many" scientific programs)
the occurrance of FDIV is much lower than the worst case given
above.
Regards,
Brian
--------------------------------------------------------------------
Any opinions inadvertantly stated here are certainly NOT the opinions
of the Hewlett-Packard Company.
DOYLE PATRICK
Trangdaithi Hoang <tho...@orion.oac.uci.edu> wrote:
>The frequency of the bug, as you claim, is once in nine billion
>floating point divides. According to the Intel Pentium reference
>one FDIV floating point divide takes 39 cycles. A 90 MHz Pentium
>running at 90,000,000 cycles per second can execute roughly
>2,307,692 FDIV floating point divides per second (90,000,000 / 39).
>Therefore, an error will occur at a frequency of about ONCE EVERY
>3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
>Pentium. The frequency of the error increases as the speed of the
>Pentium increases. A Pentium 100 MHz will encounter the error
>with a frequency of about ONCE EVERY 3510 SECONDS OR 58.5 MINUTES.
>
But how often is a pentium set up to perform nothing but FDIV for an
hour? A more representative number could be found by taking a fairly
FPU-intensive piece of software and finding out how many FDIVs it does
per second. Then use THAT number to figure on how many errors will
occur. I bet it's still fairly high, but once an hour is certainly an
absolute maximum theoretical frequency. Let's be fair here. :)
-Pat
Neep Hazarika
>BukAK!!
In short, don't listen to buzz words.
Cheers,
--
Neep Hazarika Department of Electrical and Computer Engineering
University of Queensland, St. Lucia, QLD, Australia, 4072
Phone: +61-7-365-3771 (work) +61-7-371-8892 (home) Fax +61-7-365-4999
INTERNET: ne...@hebb.elec.uq.oz.au OR ne...@s1.elec.uq.oz.au
Charles Eicher
PATRICK) wrote:
> But how often is a pentium set up to perform nothing but FDIV for an
> hour? A more representative number could be found by taking a fairly
> FPU-intensive piece of software and finding out how many FDIVs it does
> per second. Then use THAT number to figure on how many errors will
> occur. I bet it's still fairly high, but once an hour is certainly an
> absolute maximum theoretical frequency. Let's be fair here. :)
Not even CLOSE! Doesn't anyone study probability anymore?
I accept that there is a problem with the original description of the
situation, that software rarely just sits there and does FDIV all day. But
then, there's nothing in probability about 'maximum theoretical
frequency'.. That's like using the 'law of averages'..
Someone do the math cause I'm too tired, its late. In the described
situation where you're just doing FDIVs with truly random numbers, there's
a distribution curve for the duration you can go without hitting the bug.
It might happen on the first try. You might never hit it. Somewhere
inbetween there's a peak on the curve, the mean duration when you're most
likely to hit. The exact duration is left to the reader as an exercise.
-----------------------
Charles Eicher
cei...@ins.infonet.net
-----------------------
Randolph Fritz
>
>Mr. Grove did address the FDIV frequency by essentially stating
>that in a typical program (including "many" scientific programs)
>the occurrance of FDIV is much lower than the worst case given
>above.
>
This of course is true and perfectly irrelevant to the issues
reliabilty raised. Fact of the matter is, we just don't know how much
it matters, or how many programs will be affected. It's conceivable
that the right program with the right data will result in a string of
these errors; program data isn't random. We know empirically that
doesn't happen very often, problem is, it may make a difference in
some life-threatening situation.
R.
Toupau Xiong
[...old comments snip...]
>
>
>Scott,
>
>Yes, I do have a buggy Gateway P5-90 system. No, I have not yet had the
>time to call the posted number, but I am assuming they *will* replace the
>chip because of how I use it. If they do not replace it, that will
>probably be another story.
>
>I see all the flames here about Mr Groves response, but I felt it was a
>fair one as long as they do solve the problems to the customers
>satisfaction. I guess that still remains to be seen.
>
>Larry
>
I will never satisfy with this buggy deal if Intel does not replace any
buggy cpu requested by a customer. Even if Intel replace my cpu because
my job involve intensive numerical calculation, I won't be happy with
Intel. Intel should replace its buggy cpu no matter what the user is
using the chip for, every Pentium user pays Intel about the same $.
I do use intensive math calculations, but that doesn't mean my $1.00 worth
more than someone who does not do math calculations $1.00. It's totally
unfair treatment for Pentium customers.
Tou
--
________________________________ ___ ___
| \ | / Tou Xiong | | This section is under |
| -- o -- t...@cda.mrs.umn.edu | | heavily construction, |
| / | \ Copyright 1994 | | please put on your hard hat. |
`--------------------------------' `--- ---'
John Groseclose
> >In article <3bb5bv$q...@inewssc.intel.com>,
> >The frequency of the bug, as you claim, is once in nine billion
> >floating point divides. According to the Intel Pentium reference
> >one FDIV floating point divide takes 39 cycles. A 90 MHz Pentium
> >running at 90,000,000 cycles per second can execute roughly
> >2,307,692 FDIV floating point divides per second (90,000,000 / 39).
> >Therefore, an error will occur at a frequency of about ONCE EVERY
> >3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
> >Pentium. The frequency of the error increases as the speed of the
> >Pentium increases. A Pentium 100 MHz will encounter the error
> >with a frequency of about ONCE EVERY 3510 SECONDS OR 58.5 MINUTES.
Hmmm. I know a few doctors running their imaging software on Pentiums. A
few civil engineers doing their calculations, too.
I'd hate to see one of these "minor" errors appear in any of their projects.
--
John Groseclose <car...@enet.net> WWW site: HTTP://ias.west.asu.edu/
Another person who will NEVER buy anything inappropriately
advertised on the UseNet...
*Unsolicited Commercial EMail will be proofread for $100 per message*
willie* chang
(emb121) wrote:
But there're so many buggy Pentium out there (over 50,000,000?) And it's
happening here and there almost every hour or so. An analogy is 1 time
bomb (randomly timed) blows in 270,000 years (if there's only 1 Pentium)
but when you have over 50 million time bombs laying around, bleah?
Intel plays the probabilistic logic game by isolating each user into
believing the singleton statistic so that everyone would said to
him/herself: No, it's not gonna happen to me...let other people die...
Just like when an airplane went down, the statistics is still safer
than driving, and you're glad it's not you, and the airline says it's about
in 350 million years you'll crash in a flight. But isn't that a mind-
cheating game that Intel is playing and let our own confusion bury
ourselves in comp.sys.intel?
Looks like the Big Brother is dictating inside his giant corp like this:
"Each of you is a single cell in the great body of the State. And today,
that great body has purged itself of parasites. We have triumphed over the
unprincipled dissemination of facts. The thugs and wreckers have been cast
out. Let each and every cell rejoice! For today we celebrate the first
glorious anniversary of the Information Purification Directive. We have
created, for the first time in all history, a garden of pure ideology where
each worker may bloom secure from the pests purveying contradictory and
confusing truths. Our unification of thought is more powerful a weapon than
any fleet or army on earth. We are one people. With one will. One
resolve. One cause. Our enemies shall talk themselves to death, and we
will bury them with their own confusion. We shall prevail."
willie*
Campbell Robertson
(willie* chang) wrote:
> Looks like the Big Brother is dictating inside his giant corp like this:
> "Each of you is a single cell in the great body of the State. And today,
> that great body has purged itself of parasites. We have triumphed over the
> unprincipled dissemination of facts. The thugs and wreckers have been cast
> out. Let each and every cell rejoice! For today we celebrate the first
> glorious anniversary of the Information Purification Directive. We have
> created, for the first time in all history, a garden of pure ideology where
> each worker may bloom secure from the pests purveying contradictory and
> confusing truths. Our unification of thought is more powerful a weapon than
> any fleet or army on earth. We are one people. With one will. One
> resolve. One cause. Our enemies shall talk themselves to death, and we
> will bury them with their own confusion. We shall prevail."
And to bring the above more into line with the original commercial....
"In 1994, Intel will confirm that the Pentium can't do math. And you'll
find out why 1994 will be just like '1984'."
:-)
--
Campbell
Mike Burns
What kind of an application just does FDIVs and prints the results?
If a program is doing a simulation for an hour and a wrong result is
produced only once but half way through the hour, then it is likely that
as many as half of the results in that hour are wrong. If any of those
are critical to the correct final result, then it does not matter how
many correct partial results were generated, the whole hour is wasted
computing.
The simplistic analysis posed by Intel is a smokescreen.
In article <ceicher-0112...@s125.infonet.net>,
--
/-------------- SAS Web: http://www.unx.sas.com/~sasmkb/Home.html ----------\
| Michael Burns SAS Institute, Inc. email: sas...@sas.com |
| Mgr. Development Tools PO Box 200075 personal: mbu...@bga.com |
| Software Development Dept. Austin, TX 78720-0075 |
| Austin Regional Office voice: (512)258-5171 fax: (512)258-3906 |
+----------------------------------------------------------------------------+
| "choose for yourselves today whom you will serve;... |
| but as for me and my house, we will serve the Lord." Joshua 24:15 |
Brian Stone
I am surpised no one mentioned this...
Find the Intel newsgroup (yes, there is one)... and just see how
many people are complaining about this bug. Nearly Everyone!
They have written software that you can probably ask for, if you
want, that will show you the FP BUG on a P-90.
I dont care what anybody says... ANY BUG that you can view On
Purpose is a SERIOUS BUG. Apparently, Intel advocates around the world
agree.
BAS
Chris Umbricht, M.D.
emb...@hearst.cac.psu.edu writes:
>That is, of course, if your Pentium does nothing other than call FDIV.
>If your programs don't call FDIV (which they won't if they're not doing
floating point math) then you'll never see the bug at all.<
Quite right. Confirming that the whole argument about how frequent the
problem occurs is completely meaningless... no?
Trangdaithi Hoang
David Springer
>Thank you, Mr. Grove, for pointing out the severity and frequency of the
>bug. Allow me to clarify what you've just said in a way most people
>can understand.
>The frequency of the bug, as you claim, is once in nine billion
>floating point divides. According to the Intel Pentium reference
>one FDIV floating point divide takes 39 cycles. A 90 MHz Pentium
>running at 90,000,000 cycles per second can execute roughly
>2,307,692 FDIV floating point divides per second (90,000,000 / 39).
>Therefore, an error will occur at a frequency of about ONCE EVERY
>3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
>Pentium. The frequency of the error increases as the speed of the
>Pentium increases. A Pentium 100 MHz will encounter the error
>with a frequency of about ONCE EVERY 3510 SECONDS OR 58.5 MINUTES.
Forgive my ignorance, but what application do you use that manages to
generate 18 billion meaningful floating point input operands and
utilize the 9 billion double precision dividends once every 39 clock
cycles ? Maybe I'm just naive but isn't there a *lot* of other stuff
that has to happen besides the divide in order to do something with
the result ?
While the once every 127,000 years is probably accurate for the
average of all Pentium users I've little doubt that the figure is
substantially less for heavy duty number crunching applications.
However, you purposely saying it's once per hour is inflammatory and
quite untrue. No application can possibly generate double precision
divides at anywhere near the rate you claim and accomplish anything
useful.
While I'm certainly not an Intel apologist I *am* interested in an
honest assessment of the problem and you sir have done nothing in that
regard. What you might accomplish is Intel recalling millions of
Pentium CPU's at a cost of tens of millions to Intel and untold
millions to people who will never have a problem but will panic and
demand their computer be taken off-line and the part replaced. That
is irresponsible and reprehensible, quite akin to yelling fire in a
crowded theater when no fire exists.
Aside from the needless damage to parties named and unamed above who
do you think is going to pay for this ? Intel ? Don't be naive.
Intel will pass the cost on to their customers, which is to say you
and I.
David Springer
Systems Programmer
Dell Computer Corporation
<These are personal opinions and do not represent the opinions of my
employer.>
David Springer
>This of course is true and perfectly irrelevant to the issues
>reliabilty raised. Fact of the matter is, we just don't know how much
>it matters, or how many programs will be affected. It's conceivable
>that the right program with the right data will result in a string of
>these errors; program data isn't random. We know empirically that
>doesn't happen very often, problem is, it may make a difference in
>some life-threatening situation.
Mr. Fritz,
Consider that in a typical PC the Pentium Processor represents several
millions of logic gates. The rest of the PC contains at least 10
times that number and any part of it is subject to errors ranging from
Alpha particles striking a non-rad hardened memory cell, to disk
errors, to power supply fluctuations and lightning strikes, to once
per billion operation flaws in any of the millions of lines of source
code in the firmware, the operating system, or the application. If
you have an application which is so sensitive to a double precision
floating point operation coming back a single precision floating point
operation that it will cause catastrophic results I humbly submit to
you that you shouldn't be using a desktop PC in such a casual manner.
You are MUCH more likely to suffer from an error in any one of the
literally millions of other pieces of that computer and software
controlling it's operation.
David Springer
Systems Programmer
Dell Computer Corporation
<These are person opinions and do not represent the opinions of my
employer>
Kimberley Burchett
--
Kimberley <OK...@max.tiac.net>
Phillip Burgess
>"In 1994, Intel will confirm that the Pentium can't do math. And you'll
>find out why 1994 will be just like '1984'."
Intel, where quality is job 0.9999987324
--
Phillip Burgess (pbur...@netcom.com) >belch<
W. Donald Rolph III
>few civil engineers doing their calculations, too.
>I'd hate to see one of these "minor" errors appear in any of their projects.
>--
>John Groseclose <car...@enet.net> WWW site: HTTP://ias.west.asu.edu/
>Another person who will NEVER buy anything inappropriately
>advertised on the UseNet...
>*Unsolicited Commercial EMail will be proofread for $100 per message*
How many people now feel comfortable about performing their simulations on
pentiums?
It would seem to me that INTEL is facing as a minimum a public relations
meltdown, and is potentially risking liability problems since they do not
appear to taking proactive action to deal with this issue.
I dont believe I have another computing vendor who would be so blase' about
this defect.
Regards.
Don Rolph w-r...@ds.mc.ti.com WD3 MS10-13 (508)-699-1263
-A.RIZZO
>the conversations that have been taking place here.
>
>...
>
>This group [Intel QA] concluded after months of work that (1) an error
>is only likely to occur at a frequency of the order of once in nine
>billion random floating point divides, ...
>
>Andy Grove
Hmmm! I drove through a stop-sign last week, without stopping,
and nothing happened. I did it again Monday, and nothing
happened again. Since Monday I've driven through stop-signs
nineteen times more, and nothing has happened. Clearly, driving
through stop-signs is a safe practice. I guess I'll just keep
doing it.
Tony Rizzo
H. Anders Lonnemo
says:
>
>
>Consider that in a typical PC the Pentium Processor represents several
>millions of logic gates. The rest of the PC contains at least 10
>times that number and any part of it is subject to errors ranging from
>Alpha particles striking a non-rad hardened memory cell, to disk
>errors, to power supply fluctuations and lightning strikes, to once
>per billion operation flaws in any of the millions of lines of source
>code in the firmware, the operating system, or the application. If
>you have an application which is so sensitive to a double precision
>floating point operation coming back a single precision floating point
>operation that it will cause catastrophic results I humbly submit to
>you that you shouldn't be using a desktop PC in such a casual manner.
>You are MUCH more likely to suffer from an error in any one of the
>literally millions of other pieces of that computer and software
>controlling it's operation.
>
>David Springer
>Systems Programmer
>Dell Computer Corporation
>
><These are person opinions and do not represent the opinions of my
>employer>
>
Mr. Springer,
I have to point out that all of the possible errors that you listed, and people should
be cognizant of them, are of a "one-time" nature. Whereas the Pentium bug
is repeatable. This distinction is not trivial. The plain truth is that the Pentium chip
is defective, it does not work as advertised (no matter how infrequently), and Intel
will probably be forced to replace them all. I am personally astonished at how
poorly they have handled this whole situation. The bottom line is that the integrity
of the chip and any computer it is in has been shattered.
Regards,
Anders
P.S. Much has been said about the ramifications of this "bug" in intensive calculations, but
amongst it all I haven't seen anybody point out that algorithms which converge on
solutions will probably be unaffected.
ryan
>While I'm certainly not an Intel apologist I *am* interested in an
>honest assessment of the problem and you sir have done nothing in that
>regard. What you might accomplish is Intel recalling millions of
>Pentium CPU's at a cost of tens of millions to Intel and untold
>millions to people who will never have a problem but will panic and
>demand their computer be taken off-line and the part replaced. That
>is irresponsible and reprehensible, quite akin to yelling fire in a
>crowded theater when no fire exists.
>
>Aside from the needless damage to parties named and unamed above who
>do you think is going to pay for this ? Intel ? Don't be naive.
>Intel will pass the cost on to their customers, which is to say you
>and I.
So just roll over and forget about it, right? Never mind that I have been
saving money for months to buy a computer from DELL(because of DELL's
great *service* and *support* to customers) and now I find that it *will* be
worth less to sell a year from now than another machine bought a few months
later. And because of a bug that was discovered last summer? And unreported?
I *don't* care if I never see the bug. I *don't* care if it's such a small error.
There are individuals out there whose money seems to be worth more to Intel
than mine. A corporation cannot in good conscience have a conditional replacement
policy for an acknowleged fault in a product. What about warranties, like DELL's,
which cover defects in manufactuing and materials? Please help me to understand
how I'm supposed to let this go. And not from the point of big business.
What about ethics?
>David Springer
>Systems Programmer
>Dell Computer Corporation
>
><These are personal opinions and do not represent the opinions of my
>employer.>
I would have to say you have summed up very well the opinions of your employers.
ryan shaw, DELL customer, for what it's worth.
rys...@xmission.com snow, snow, snow, snow, snow, snow.
http://www.xmission.com/~ryshaw
"Pass the salt, pour it in my wounds." -Quicksand
Bruce Clarke
> In article <neep.786258206@sgi>, ne...@sgi.elec.uq.oz.au (Neep Hazarika) wrote:
> > >In article <3bb5bv$q...@inewssc.intel.com>,
>
> > >3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
> > >Pentium.
>
So this means one pixel is wrong for every 9 billion pixels. If a typical
image is 4000 by 6000 pixels (4 times the Kodak Photo CD resolution) then
one out of every 300,000 images will have a wrong pixel. A speck of dust
on a negative is a far more serious problem.
> A few civil engineers doing their calculations, too.
So this means the strenght of one piece out of every 9 billion pieces might be
weaker. It should be 1.000000000 but the calculation will give 0.99999999.
Since engineering calculations are a based on a very wide safety margin, (like
20% ?), the safety margin will be 19.9999999% when it should be 20%?
> I'd hate to see one of these "minor" errors appear in any of their projects.
I suppose you would worry about the moon falling out of the sky and hitting
you too.
--
---------------------------------------------------------------------
Bruce Clarke | internet: Bruce....@ualberta.ca
Department of Chemistry | compuserve: 70740,3135
University of Alberta | phone voice (403) 492-5739
Edmonton AB, T6G 2G2 | phone fax (403) 492-8231
Canada | WWW server: www.chem.ualberta.ca
Bruce Clarke
> Part of the argument posed assumes that each FDIV stands alone.
> What kind of an application just does FDIVs and prints the results?
> If a program is doing a simulation for an hour and a wrong result is
> produced only once but half way through the hour, then it is likely that
> as many as half of the results in that hour are wrong. If any of those
> are critical to the correct final result, then it does not matter how
> many correct partial results were generated, the whole hour is wasted
> computing.
The problem with this newsgroup is that hardly anyone seems to know anything
about how their software actually works. I write a lot of software for
scientific calculations on non-linear dyanamics and chaos. I also teach a
course on numerical methods. Let me try to explain the real issues.
The real issue here is chaos versus stability. All numerical algorithms are
designed to be stable. All calculations have round-off errors and the
cumulative effect of the round-off errors must not be allowed to affect the
results. This is achieved by using algorithms that are stable. Most of the
time FDIV's are being used, some numerial algorithm is trying to converge on a
result. If one step during this convergence process is calculated slightly
wrong, two outcomes are possible:
(1) if the deviation remains within the region where convergence occurs to the
desired result, the same result will be obtained. It might take an extra
iteration.
(2) if the deviation is outside the region where convergence occurs, most
numerical algorithms go wild and give error messages. Often the algorithm
detects such situations and recovers from them. In the latter case, the
software is likely to restart the calculation with slightly different data and
then it should converge without hitting the troublesome numbers where the FDIV
problem occurs. The result is again the same.
If the FDIV did cause a failure to converge in this situation, any properly
designed software would give the user an error message. There are all sorts of
reasons why some software doesn't converge. Well designed software should
detect the FDIV error as just another failure to converge.
The one time when such a error would change the result is if you were
simulating chaotic dynamics. By definition, chaos is sensitivity to the
initial conditions. So if you change even the last digit, the future will
change. In that case you would get a completely different trajectory as a
result of the error.
The world's weather is chaotic and it is well known that adding the flapping
of a butterfly's wings in Japan can change the outcome so drastically a new
hurricane could occur in Brazil a few weeks later. -- the famous "Butterfly
effect".
However, nobody tries to predict chaotic dynamics because the errors in the
data make the predictions wrong. Usually people try to get a statistical
picture of the chaos. The errors produced by the incorrect FDIV are likely to
be random, and be equivalent to choosing different starting points for the set
of trajectories used to gather statistical information about the chaos. The
statistical results wouldn't change.
The one situation where I think FDIV might produce a problem is the following.
Suppose you were trying to trace a curve and you had a complex numerical
algorithm which converges to the curve. As long as there was a fairly large
domain about the curve where convergence to the curve occurred, the FDIV
wouldn't cause a problem. But suppose you tried to push the software into
calculating the curve in the most difficult situations, where the software had
great difficulty converging to the curve. In this situation the FDIV might
just throw the calculation off enough to make following the curve much more
difficult. Since a faulty FDIV should only occur about once an hour, a problem
would occur if the curve you are tracing is so hard to calculate that the
Pentium spends an hour trying to converge to typical points on the curve.
I think all this fuss is from people who know absolutely nothing about how
their software actually works. The only cases where the FDIV would be a real
problem is when the numerical algorithms themselves are dealing with
calculations of very great complexity using algorithms that are just barely
stable.
Programs like this never end up in the hands of the general public. Some of my
own programs do work this way. We have lots of parameters we can control to
fine tune the calculations and we have to spend a lot of time tuning these
parameters to get the computer to follow the curve we want to calculate. Even
with my software, the actual time spent calculating a curve is short enough
that an error which only occurs once an hour is unlikely to cause a problem.
I really don't think the FDIV is anything to get exited about.
Christopher J. Vogt
--
Christopher J. Vogt vo...@netcom.com
From: El Eh, CA
John Groseclose
(Trangdaithi Hoang) wrote:
IMHO, an error like this with freq > 0 is unacceptable.
Remember what caused the Challenger to explode? A simple gasket that got a
few degrees too cold? How many calculations for the space program would be
made on Pentium? Probably not many. What about someone who's calculating
other things, though, like stress/load-bearing capability?
I'd think you would get might upset if the collapse of, say, a building or
bridge killed some people as a direct result of that statistically
improbable division error.
I use a computer to do most of my math work (granted, most of my math work
is personal finances... Easy to do, as I don't have much cash flow at this
point) because I trust that the computer can do the math better, faster,
and more accurately than I can.
Michael Page
>tho...@orion.oac.uci.edu (Trangdaithi Hoang) writes:
>
>>Therefore, an error will occur at a frequency of about ONCE EVERY
>>3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
>>Pentium.
>
>generate 18 billion meaningful floating point input operands and
>utilize the 9 billion double precision dividends once every 39 clock
>cycles ?
I disagree with your point. Mr Hoang's result is not useful as an
exact measure of how often most people (even number crunchers) will
encounter the bug, but it does give an indication of the *upper bound*
on the error frequency, in the same way that Intel's `once every 27,000
years' gives another indication of the frequency. (I'm still wondering
how the latter figure was arrived at.)
It is also a very useful indication of the *order of magnitude* of the
frequency, and confirms the `once every two hours' result given by
the person using a random number generator. For heavy number crunching
we can expect the frequency to be of the order of (hours)^(-1) and
not (years)^(-1). This is very important.
>While the once every 127,000 years is probably accurate for the
>average of all Pentium users I've little doubt that the figure is
>substantially less for heavy duty number crunching applications.
Mr Hoang's should have told you how much less, if you'd used some
common sense, instead of a knee-jerk reaction.
>While I'm certainly not an Intel apologist I *am* interested in an
>honest assessment of the problem and you sir have done nothing in that
>regard.
Wrong. See above.
>David Springer
>Systems Programmer
>Dell Computer Corporation
If this, my own conversations with Dell Australia, and Jonathan Kamen's
problems with getting a straight answer from Dell are representative of
Dell's attitude to the matter then they won't be selling me the computer
I was about to buy. Really.
Dell are a big company; they should be standing up for their customers
and using their muscle to get replacement chips from Intel from people
who are concerned enough to go to the trouble to ask for someone to
replace them, and who have a good reason.
Michael
--
Michael Page ObMotto: Non carborundum illegitimi \
m...@hal.maths.monash.edu.au \
Mathematics Department, Monash University, Melbourne, Australia \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
ggcarter
Absolutely, the most hilarious and most outragous thread I have ever
read in my 10 years on Usenet.
The humour in this newgroup makes me proud to be a Mac owner.
It just goes to prove, rewriting the laws of Mathematics only requires
a 80% market share, not so much a BS, MS, or PhD.
:)
------------------------------------------------------------------------
--------
Gregory Carter | "I value peace of
mind and
Unix Network Administrator (Among other things) | silence, more than
anything
Promega Corporation | else in life."
gca...@promega.com (aka ro...@promega.com) | Myself at age 10
Randolph Fritz
David Springer <spri...@dellgate.us.dell.com> wrote:
>
>Mr. Fritz,
>
>Consider that in a typical PC the Pentium Processor represents several
>millions of logic gates. The rest of the PC contains at least 10
>times that number and any part of it is subject to errors ranging from
>Alpha particles striking a non-rad hardened memory cell, to disk
>errors, to power supply fluctuations and lightning strikes, to once
>per billion operation flaws in any of the millions of lines of source
>code in the firmware, the operating system, or the application. If
>you have an application which is so sensitive to a double precision
>floating point operation coming back a single precision floating point
>operation that it will cause catastrophic results I humbly submit to
>you that you shouldn't be using a desktop PC in such a casual manner.
>You are MUCH more likely to suffer from an error in any one of the
>literally millions of other pieces of that computer and software
>controlling it's operation.
>
The problem is that the mathematical error is *not* random. The right
combination of algorithm and data may instead provoke a cascade of
errors. This is an experience I've had time & again in software
development and testing; an apparently unlikely error, because of the
right combination of algorithm and data, will actually occur quite
frequently. There is no good way of preventing this short of a great
deal of software work or replacing the unreliable hardware.
R.
Geoffrey Smith
Excuse me for asking a silly question, but,
How was the bug found? Was it found by someone sitting around doing double
precision divides all day? Or was it found by someone actually using
their computer as a tool, expecting to find the correct answer and not?
thanks,
Sinan Karasu
Bruce Clarke <Bruce....@ualberta.ca> wrote:
>In article <caradoc-0112...@tecate.enet.net> car...@enet.net (John Groseclose) writes:
>> In article <neep.786258206@sgi>, ne...@sgi.elec.uq.oz.au (Neep Hazarika) wrote:
>> > >In article <3bb5bv$q...@inewssc.intel.com>,
>>
>> > >Therefore, an error will occur at a frequency of about ONCE EVERY
>> > >3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
>> > >Pentium.
>>
>> Hmmm. I know a few doctors running their imaging software on Pentiums.
>
>So this means one pixel is wrong for every 9 billion pixels. If a typical
>image is 4000 by 6000 pixels (4 times the Kodak Photo CD resolution) then
>one out of every 300,000 images will have a wrong pixel. A speck of dust
>on a negative is a far more serious problem.
No it would mean those pixels computing to the same faulty value, will have
the same error and you will have a region in worst case that suddenly developes
an edge.
>
>> A few civil engineers doing their calculations, too.
>
>So this means the strenght of one piece out of every 9 billion pieces might be
>weaker. It should be 1.000000000 but the calculation will give 0.99999999.
>Since engineering calculations are a based on a very wide safety margin, (like
>20% ?), the safety margin will be 19.9999999% when it should be 20%?
No. See above..... However this case probably will have no effect, unlike the
image processing case above.....
Carl Oppedahl
>rand...@netcom.com (Randolph Fritz) writes:
>>This of course is true and perfectly irrelevant to the issues
>>reliabilty raised. Fact of the matter is, we just don't know how much
>>it matters, or how many programs will be affected. It's conceivable
>>that the right program with the right data will result in a string of
>>these errors; program data isn't random. We know empirically that
>>doesn't happen very often, problem is, it may make a difference in
>>some life-threatening situation.
>Consider that in a typical PC the Pentium Processor represents several
>millions of logic gates. The rest of the PC contains at least 10
>times that number and any part of it is subject to errors ranging from
>Alpha particles striking a non-rad hardened memory cell, to disk
>errors, to power supply fluctuations and lightning strikes, to once
>per billion operation flaws in any of the millions of lines of source
>code in the firmware, the operating system, or the application. If
>you have an application which is so sensitive to a double precision
>floating point operation coming back a single precision floating point
>operation that it will cause catastrophic results I humbly submit to
>you that you shouldn't be using a desktop PC in such a casual manner.
>You are MUCH more likely to suffer from an error in any one of the
>literally millions of other pieces of that computer and software
>controlling it's operation.
You don't get it, do you? Those other things you refer to, like alpha
particles and all -- they would not cause two successive runs of the program
to misbehave in the same way. They would not cause two machines running side
by side to get the same erroneous result. Some of them would reveal
themselves to the user, for example by crashing the system.
The FDIV flaw causes two successive runs of the program to misbehave in the
same way. It causes two machines running side by side to get the same
erroneous result. It does not result in a crash or any other overt sign of
failure.
Carl Oppedahl
Oppedahl & Larson, patent law firm
oppe...@patents.com
watch this space for a web server with frequently asked patent questions and answers
Rick C. Hodgin
If the doctors are using Pentiums for that type of thing, why not just go
back to an 80486/DX4 100 until the debugged pentiums come out? I mean
sure, it might take a few more minutes to process...but it might save a
patient down the line. I'd say a few seconds now is worth an eternity in
hell for mal-practice, wouldn't you?
Fox
Ed Hall
: In article <caradoc-0112...@tecate.enet.net> car...@enet.net (John Groseclose) writes:
: > In article <neep.786258206@sgi>, ne...@sgi.elec.uq.oz.au (Neep Hazarika) wrote:
: > > >Therefore, an error will occur at a frequency of about ONCE EVERY
: > > >3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
: > > >Pentium.
: >
: > Hmmm. I know a few doctors running their imaging software on Pentiums.
: So this means one pixel is wrong for every 9 billion pixels. If a typical
: image is 4000 by 6000 pixels (4 times the Kodak Photo CD resolution) then
: one out of every 300,000 images will have a wrong pixel. A speck of dust
: on a negative is a far more serious problem.
It doesn't work that way. The projection calculations used in
tomographic imaging (CAT, MRI, etc) don't even work with pixels until
just before the final image is generated. An error in an intermediate
value could affect many pixels.
If you want to claim that a divide error is harmless or unlikely in a
particular case, spend some time researching the algorithms involved and
then study the peculiar distribution of the faulty divide operands (it's
hardly uniform--bad operands cluster in a small neighborhood around
certain integers; see the series of messages by Tim Coe for details).
Some algorithms might be especially prone to the bug, while others are
essentially immune to it. You're only stooping to the same hysteria
as your adversaries by making unsubstantiated claims without a thorough
examination of the facts.
Frankly, there are so many unanswered questions at this point that
it is impossible to say how large the group of materially affected
users really is. If you disagree with this, by all means, present
your case, but it better have a strong analytical basis that goes
beyond the fuzzy statistical arguments we've seen so far from both
sides.
There are other issues, of course: issues of morality, economics,
corporate policy, and so forth. But are any of these issues really
appropriate to these newsgroups?
-Ed Hall
edh...@rand.org
Jon Jenkins
: tho...@orion.oac.uci.edu (Trangdaithi Hoang) writes:
.... deleted.
With all due respect David you are quite incorrect.
Many numerical applications are load/FDIV/FMUL/store (to use
RISC terminology) intensive. Examples such as finite element
analysis, matrix solution (both exact and iterative), neural
nets, fluid and thermal dynamics etc etc. Thes "simulations"
may continue for many hours or sometimes days with results
being propagated from beginning to end. It is also known
that many of these systems are not stable at single precision
hence the need and IEEE standards for double precision.
Again with all due respect to your position at Dell you
really should not comment on technical issues
on which you are clearly not familiar.
: honest assessment of the problem and you sir have done nothing in that
: regard. What you might accomplish is Intel recalling millions of
: Pentium CPU's at a cost of tens of millions to Intel and untold
: millions to people who will never have a problem but will panic and
: demand their computer be taken off-line and the part replaced. That
: is irresponsible and reprehensible, quite akin to yelling fire in a
: crowded theater when no fire exists.
I agree to a certain extent, there has been a lot of hysteria. In your
official capacity you could bring pressure upon Intel to release
all the technical information regarding the bug so that those
most affected could make a proper assessment of the situation. Intels
quoted incidence of 1/27000 years does NOT apply to the majority
of Pentium owners in this forum and your comments may be better
directed at the popular media. In trying to defuse the situation
here you have only served to infalme it more.
: David Springer
: Systems Programmer
: Dell Computer Corporation
----------------------------------------------------------------------
Name: Dr Jon Jenkins
Location: Digital Equipment Corp, NaC,
Burnett Place, Research Park,
Bond University, Gold Coast
QLD, AUSTRALIA 4229
Phone: 61-75-75-0151
Fax: 61-75-75-0100
Internet: jenk...@ozy.dec.com
The opinions expressed above are entirely personal and do not
reflect the corporate policy of DEC or the opinions of DEC management.
-----------------------------------------------------------------------
Chris Umbricht, M.D.
car...@enet.net writes:
./.
>> >Quite right. Confirming that the whole argument about how frequent
the problem occurs is completely meaningless... no?< <<
>>
>> Thank you, sir. Someone finally sees my point. =)
>
>IMHO, an error like this with freq > 0 is unacceptable.<
I quite agree. I sure would not want one of those chips. Of course, I
would not want a 486 either, but that's another matter... ;-)
Chris Umbricht, M.D.
spri...@dellgate.us.dell.com writes:
>What you might accomplish is Intel recalling millions of
>Pentium CPU's at a cost of tens of millions to Intel and untold
>millions to people who will never have a problem but will panic and
>demand their computer be taken off-line and the part replaced.<
Well, yes, maybe. So what? Is'nt that what Intel SHOULD be at least
offering?
>That is irresponsible and reprehensible, quite akin to yelling fire in
>a crowded theater when no fire exists.<
Oh, is that the current thinking at Dell as well? How would YOU define a
fire?
And not telling anyone what you know for several months IS NOT
"irresponsible and reprehensible" ?
It must have something to do with this attitude that this great country
has more lawyers than everyone else combined...
Benjamin S. Yu
ben
Bob Maher
cei...@ins.infonet.net (Charles Eicher) wrote:
> In article <D046n...@ecf.toronto.edu>, doy...@ecf.toronto.edu (DOYLE
> PATRICK) wrote:
>
> > But how often is a pentium set up to perform nothing but FDIV for an
> > hour? A more representative number could be found by taking a fairly
> > FPU-intensive piece of software and finding out how many FDIVs it does
> > per second. Then use THAT number to figure on how many errors will
> > occur. I bet it's still fairly high, but once an hour is certainly an
> > absolute maximum theoretical frequency. Let's be fair here. :)
>
> Not even CLOSE! Doesn't anyone study probability anymore?
>
> I accept that there is a problem with the original description of the
> situation, that software rarely just sits there and does FDIV all day. But
> then, there's nothing in probability about 'maximum theoretical
> frequency'.. That's like using the 'law of averages'..
>
> Someone do the math cause I'm too tired, its late. In the described
> situation where you're just doing FDIVs with truly random numbers, there's
> a distribution curve for the duration you can go without hitting the bug.
> It might happen on the first try. You might never hit it. Somewhere
> inbetween there's a peak on the curve, the mean duration when you're most
> likely to hit. The exact duration is left to the reader as an exercise.
>
> -----------------------
> Charles Eicher
> cei...@ins.infonet.net
> -----------------------
It's WAY too late now, but the distribution you seek is the following:
If the probability of getting the error on a given calculation is p, and
the number of FDIV's per second is D, then the probability of NOT getting
any FDIV errors for S consecutive seconds is:
(1-p)^(D*S)
This function looks like a 1/e^x- intersects the y-axis at 1, and decays
at a slower and slower rate.
I heard that it takes 39 clock cycles to do an FDIV.
IF ALL YOU DID WAS FDIVS, AND THE PROBABILITY OF THE FDIV ERROR WAS ONE IN
10 BILLION, OR 1/(10^10), then we get the following distribution for how
long it will take you to get YOUR FIRST FDIV ERROR ON A PENTIUM 90mHZ.
90*10^6 TICKS/SEC / (39TICKS/FDIV) =2,307,692.3 FDIV'S/SEC
F(S) = (.9999999999)^(2,307,692.3 S)
F(S) = (1-1/(10^10))^(2,307,692.3 S)
or approximately,
F(S) = (.999900005)^(2.307692 S)
Solving for F(S)=0.5, we get an expected time before failure of 3003
seconds, or
LESS THAN ONE HOUR!!!.
The average amount of time between FDIV errors will be
10^10/2,307,692.3 = 4333 seconds, or about 72 minutes 13 seconds.
If your concerned about the probability of getting a certain number of
FDIV errors over a time period of a given length, a poisson process, use
the following distribution applies:
f(x), the probability distribution is
f(x)=L^x e^(-L) / x!
where x! is x factorial= x(x-1)(x-2)...(2)(1),
L (lambda) is the expected number of errors in a given period, say one
hour. If the period is one hour, then f(x) is the probability distribution
of how many errors you would expect to get in one hour.
I believe this is the Bell Shaped curve you were looking for.
If there are 4333.3 seconds per error, and 86,400 seconds per day, we get
just under 20 errors per day. (19.9384615) The bell shaped curve for the
distribution of errors in a particular day is:
f(x)=20^x e^(-20) / x!
The values for 0 through 40 are:
Out[114]=
-8 -7 -6
{4.12231 10 , 4.12231 10 , 2.7482 10 , 0.000013741, 0.0000549641,
0.000183214, 0.000523468, 0.00130867, 0.00290815, 0.00581631,
0.0105751, 0.0176252, 0.0271156, 0.0387366, 0.0516489, 0.0645611,
0.0759542, 0.0843936, 0.0888353, 0.0888353, 0.0846051, 0.0769137,
0.0668815, 0.0557346, 0.0445876, 0.0342982, 0.0254061, 0.0181472,
0.0125153, 0.00834354, 0.00538293, 0.00336433, 0.00203899, 0.0011994,
0.000685374, 0.000380763, 0.000205818, 0.000108325, 0.0000555514,
0.0000277757},
or in a column:
Out[114]=
-8
4.12231 10
-7
4.12231 10
-6
2.7482 10
0.000013741
0.0000549641
0.000183214
0.000523468
0.00130867
0.00290815
0.00581631
0.0105751
0.0176252
0.0271156
0.0387366
0.0516489
0.0645611
0.0759542
0.0843936
0.0888353
0.0888353
0.0846051
0.0769137
0.0668815
0.0557346
0.0445876
0.0342982
0.0254061
0.0181472
0.0125153
0.00834354
0.00538293
0.00336433
0.00203899
0.0011994
0.000685374
0.000380763
0.000205818
0.000108325
0.0000555514
0.0000277757
Note that the probability of getting NO ERRORS in any given day is only
about one in 24,260.
While this is certainly a worst case scenario, it certainly is not once in
27,000 years.
Robert W. Maher
--
Bob Maher |My views do not nec-
Department of Managerial Economics |essarily represent
and Decision Sciences |those of my employer.
Kellogg Graduate School of Management|But they might.
Northwestern University |
Maher's Axiom: Whatever productivity gains you may realize
over the life of your computer, are easily overshadowed by
the amount of time you spend playing with it after you
first purchase it. And if it's a Pentium......
Bob Maher
Nick Maclaren
|>
|> The problem with this newsgroup is that hardly anyone seems to know anything
|> about how their software actually works. I write a lot of software for
|> scientific calculations on non-linear dyanamics and chaos. I also teach a
|> course on numerical methods. Let me try to explain the real issues.
If you teach such a course, then you should know better than to
post articles like the one you did.
|> ...
|>
|> If the FDIV did cause a failure to converge in this situation, any properly
|> designed software would give the user an error message. There are all sorts of
|> reasons why some software doesn't converge. Well designed software should
|> detect the FDIV error as just another failure to converge.
You are assuming that all numerical calculations are both iterative
and quickly and easily checkable, which is just not true. In fact,
it is easy to prove that your assumption is theoretically impossible.
|> ...
|>
|> I think all this fuss is from people who know absolutely nothing about how
|> their software actually works. The only cases where the FDIV would be a real
|> problem is when the numerical algorithms themselves are dealing with
|> calculations of very great complexity using algorithms that are just barely
|> stable.
This is complete nonsense. May I assume that you are familiar with
elementary methods for the solution of linear equations?
Consider a large matrix, with a rather poor condition number (say
10^6). Given IEEE DP hardware, the results will be accurate to
9-10 significant figures. If the FDIV bug occurs in the
calculation of a pivot, the results will be nonsense. This is a
significant difference on a well-known stable problem.
You will ask why this should matter, because the original data are
probably only accurate to a few significant figures anyway. The
point is that the results will be inconsistent with the matrix,
and invariants that would have been preserved will not be. If the
calculation as a whole would give acceptable precision (say 2-3
figures), under the assumption that all intermediate results are
consistent to at least 6 figures, then a working program will give
wrong answers.
|> Programs like this never end up in the hands of the general public. Some of my
|> own programs do work this way. We have lots of parameters we can control to
|> fine tune the calculations and we have to spend a lot of time tuning these
|> parameters to get the computer to follow the curve we want to calculate. Even
|> with my software, the actual time spent calculating a curve is short enough
|> that an error which only occurs once an hour is unlikely to cause a problem.
I find this statement almost unbelievable. One of the principal
moans by numerical analysts about commercial and public-domain
software is that so much of it has so little error detection. One
of the main differences between high-quality software (like the
NAG library) and poor-quality software (like Numerical Recipes) is
that the former has immensely more error detection.
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cus.cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Tim Morley
>> In article <neep.786258206@sgi>, ne...@sgi.elec.uq.oz.au (Neep Hazarika) wrote:
>> > >In article <3bb5bv$q...@inewssc.intel.com>,
>>
>> > >Therefore, an error will occur at a frequency of about ONCE EVERY
>> > >3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
>> > >Pentium.
>>
>> Hmmm. I know a few doctors running their imaging software on Pentiums.
>
>So this means one pixel is wrong for every 9 billion pixels. If a typical
>image is 4000 by 6000 pixels (4 times the Kodak Photo CD resolution) then
>one out of every 300,000 images will have a wrong pixel. A speck of dust
>on a negative is a far more serious problem.
>
>> A few civil engineers doing their calculations, too.
>
>So this means the strenght of one piece out of every 9 billion pieces might be
>weaker. It should be 1.000000000 but the calculation will give 0.99999999.
>Since engineering calculations are a based on a very wide safety margin, (like
>20% ?), the safety margin will be 19.9999999% when it should be 20%?
Bzzzz.. Wrong. If the pentium bug was a random event, then you might
be right, but its got a nasty habit of croping up for classes of
problem that deal with a division of large integers. Now if you are
doing complex modelling and have to do things like gaussian
elimination of large matrices, it is quite possible you have plenty of
division of arge integers going on, which are precisly the sort of
thing that a pentium will barf all over. You won't end up with a 1 in
10^10 error on yout saftey margin, you could end up with something
really horrible as the duff result gets itself propaged round your
model, and more and more fdiv errors crop up....
Tim M
Yan Lee
: In article <3bjaok$u...@hearst.cac.psu.edu> emb121,
: emb...@hearst.cac.psu.edu writes:
: >That is, of course, if your Pentium does nothing other than call FDIV.
: >If your programs don't call FDIV (which they won't if they're not doing
: floating point math) then you'll never see the bug at all.<
: Quite right. Confirming that the whole argument about how frequent the
: problem occurs is completely meaningless... no?
I remember intel mentioning that even for people who do heavy math on
their pentium will only see the error once in a few years. However I
viewed it a little differently. Let's estimate that about maybe 10,000
engineers/mathematicians actually use the chip for heavy math
calculations, including FDIV. So I estimate that about maybe 2 to 3
enginners will get that error every year. So hopefully these people are
working on something trivial, like how to prevent an egg from breaking
when it falls from 100 feet, not on something like a bridge, a
spaceship, or some very (un)important mathematical theory.
My point is that I think this error is a lot more significant than intel
puts it.
Tony
Omar El-Ghazzawy
computational tool.
I can hardly believe that Intel or anyone else would try to claim that this
is not a problem. They should be busy replacing chips.
-A.RIZZO
I most certainly appreciate all the effort that's been put into
estimating, both, the probability of an error occurring as a result
of the FDIV error in the pentium and the likelyhood of that error
being significant. Thank you all, for giving us the benefit
of your extensive command of probability and statistics.
However, two things continue to nag me, and I've yet to see an
adequate response. First, those of us who use computers as part
of a service, will, inevitably, face the following question from
the occasional customer: "How do you _KNOW_ that your results
have not been adversely influenced by the FDIV error?"
Please note that the answer to the above question is not "I verified
the model," or "I did a convergence study," since model verification
presumes that the computer's calculations are consistently accurate.
To verify, say, a finite element model, one typically forces the model
to duplicate a similar problem for which the solution is known or for
which experimental data are available. This serves the purpose of
verifying the sections of code needed for the solution, as well as the
analyst's proper use of the program. Since the numbers change from
solution to solution, model verification does not guarantee accuracy
in all cases, if the computer introduces errors unpredictably.
Second, some of us most assuredly will face the same question in a
courtroom. In that scenario, I suspect, the person asking the
question will likely phrase it in as damning a manner as possible.
Does any one care to attempt a satisfactory answer to the above
question?
*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
* - Tony Rizzo, P.E. - *
* AT&T Bell Laboratories *
* Room 6E-124, 67 Whippany Road, Whippany NJ 07981 *
* TEL: 201-386-2565 FAX: 201-386-2965 internet: ri...@hogpb.att.com *
*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
Bob Maher
bound on the frequency of obtaining an FDIV error. It assumes that you
will get one erroneous calculation per 10 Billion FDIVS. Some
distributions of numbers will give these errors more frequently.
I calculate an expected time before failure of 3003 seconds, or LESS THAN
ONE HOUR!!!. On average, you will experience an FDIV error every 72
minutes.
I calculate the probability distribution of the number of errors you might
see on a particular day.
NOTE:This work assumes that all you are doing is FDIV calculations, and
that your computer can do 2.3 million of them per second.
If the probability of getting the error on a given calculation is p, and
the number of FDIV's per second is D, then the probability of NOT getting
any FDIV errors for S consecutive seconds is:
(1-p)^(D*S)
This function looks like a 1/e^x- intersects the y-axis at 1, and decays
at a slower and slower rate.
I read that the Pentium takes 39 clock cycles to do an FDIV.
Robert W. Maher
_______________________________________________________________________________
Larry A. Westerman
Intel x86 chips have in the past had processor bugs. In all cases, Intel
provided a workaround, and/or fixed the bug in later chip versions.
The workaround for the divide bug is, check all divides and recompute those
suffering from this error by emulation, OR compute all divides by emulation.
Now, what is the result of this workaround? The cost of each and every
divide operation is increased by either the time to check for the bug,
and/or the time to emulate the division. Suppose you have a scientific
calculation which performs a divide every 50 operations. The divide
step may now take several dozen to several hundred machine cycles to
compute, which would easily swamp the cost of other flops in the computation.
This hardly seems like a trivial problem to me. For problems in past chips,
the workaround has been limited to a few extra cycles, or limited to
unusual (system-level) considerations like interrupt handlers. But now we
have a bug in EACH-AND_EVERY scientific and business application.
--
Larry A. Westerman | Performance Computing Inc.
949 East End Avenue | 15050 SW Koll Parkway Suite 2B
Pittsburgh PA 15221 | Beaverton OR 97006
412-243-2031 l...@lm.com.us | 503-641-1221 l...@perf.com
Julian James Bunn
[stuff from someone else deleted]
>
>The problem with this newsgroup is that hardly anyone seems to know anything
>about how their software actually works. I write a lot of software for
>scientific calculations on non-linear dyanamics and chaos. I also teach a
>course on numerical methods. Let me try to explain the real issues.
>
[pompous guff deleted]
>I really don't think the FDIV is anything to get exited about.
>
Zzzzzzzzzzzzzzzzzzzzz
-------------------------------------------------------------------------------
Julian James Bunn / CERN Computing and Networks Division. Tel.: Geneva 767 5029
Email: jul...@vscrna.cern.ch
-------------------------------------------------------------------------------
Barry Jelbert
> Aside from the needless damage to parties named and unamed above who
> do you think is going to pay for this ? Intel ? Don't be naive.
> Intel will pass the cost on to their customers, which is to say you
> and I.
>
> David Springer
.. and Intel's competitors benefit from Intel's screw-up. It's
called the free market.
Barry
Bob Maher
If we use 10 FDIV's per second, the expected time until failure is
obtained by solving (assuming 10 billion FDIV's per error)
F(S) = (.9999999999)^(10 S) = 0.5 for S
The answer is 693148000 seconds = 8022.55 days = 21.9796 years
NOT 27,000 YEARS.
We would have to be doing one FDIV every 122 seconds to get the answer of
once every 27,000 years.
F(845640560000) = (.9999999999)^(1/122 * 845640560000) = 0.5
This rate of one FDIV every two minutes would imply that if the life of
your computer was three years, you would only call FDIV
60*60*24*365*3/122 = 775,475 times,
or that your computer would only spend about 1/3 of one second over its
lifetime doing FDIVS.
Any respectable scientist at least footnotes his assumptions when stating
a result.
DEAR INTEL-- WHAT ASSUMPTIONS DID YOU USE WHEN CALCULATING THIS 27000 YEAR
EXPECTED TIME BEFORE FAILURE???????
Bob Maher
Bob Maher
If we use 10 FDIV's per second, the expected time until failure is
obtained by solving (assuming 10 billion FDIV's per error)
F(S) = (.9999999999)^(10 S) = 0.5 for S
The answer is 693148000 seconds = 8022.55 days = 21.9796 years
NOT 27,000 YEARS.
We would have to be doing one FDIV every 122 seconds to get the answer of
once every 27,000 years.
F(845640560000) = (.9999999999)^(1/122 * 845640560000) = 0.5
This rate of one FDIV every two minutes would imply that if the life of
your computer was three years, you would only call FDIV
60*60*24*365*3/122 = 775,475 times,
or that your computer would only spend about 1/3 of one second over its
lifetime doing FDIVS.
Any respectable scientist at least footnotes his assumptions when stating
a result.
DEAR INTEL-- WHAT ASSUMPTIONS DID YOU USE WHEN CALCULATING THIS 27000 YEAR
EXPECTED TIME BEFORE FAILURE???????
Bob Maher
Ernie Pittarelli
> > In article <neep.786258206@sgi>, ne...@sgi.elec.uq.oz.au (Neep Hazarika) wrote:
> > > >In article <3bb5bv$q...@inewssc.intel.com>,
> >
> > > >Therefore, an error will occur at a frequency of about ONCE EVERY
> > > >3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
> > > >Pentium.
> >
> > Hmmm. I know a few doctors running their imaging software on Pentiums.
>
> So this means one pixel is wrong for every 9 billion pixels. If a typical
> image is 4000 by 6000 pixels (4 times the Kodak Photo CD resolution) then
> one out of every 300,000 images will have a wrong pixel. A speck of dust
> on a negative is a far more serious problem.
>
are using images that are 1-bit deep! Try multiplying 4000x6000x24 bits
to get a truecolor image and see if you come up with less then
1:300,000 next time.
Ernie P.
epit...@csc.com
----------------------------------------------
These opinions are mine and not my employers.
Valentin Richter
(David Springer) wrote:
> Forgive my ignorance, but what application do you use that manages to
> generate 18 billion meaningful floating point input operands and
> utilize the 9 billion double precision dividends once every 39 clock
> cycles ? Maybe I'm just naive but isn't there a *lot* of other stuff
> that has to happen besides the divide in order to do something with
> the result ?
These 9 billion number that keeps popping up is only the _average_ case.
As everybody who played roulette knows this won't stop your Pentium from
turning in a wrong result on the _first_ floation point divide you try.
And that in turn doesn't imply that after one wrong result it will
patiently wait 9 billion FDIVs until it produces a second wrong one. But
on average...
-----
Valentin Richter
ric...@informatik.uni-muenchen.de
A statistician is someone who drowns in a creek whose average
depth is three feet. anon (at least to me)
Eric S. Boltz
> If the doctors are using Pentiums for that type of thing, why not just go
> back to an 80486/DX4 100 until the debugged pentiums come out? I mean
> sure, it might take a few more minutes to process...but it might save a
> patient down the line. I'd say a few seconds now is worth an eternity in
> hell for mal-practice, wouldn't you?
Buy a $3k machine to fix *Intel's* mistake? Just for the interim?
If you're willing to do that they you're one nice (and very rich) person.
-E
--
Eric S. Boltz
My views, opinions and statements in no way reflect those of the U.S. Gov't,
the U.S. Department of Commerce or NIST.
Valentin Richter
(David Springer) wrote:
> Consider that in a typical PC the Pentium Processor represents several
> millions of logic gates. The rest of the PC contains at least 10
> times that number and any part of it is subject to errors ranging from
> Alpha particles striking a non-rad hardened memory cell, to disk
> errors, to power supply fluctuations and lightning strikes, to once
> per billion operation flaws in any of the millions of lines of source
> code in the firmware, the operating system, or the application. If
> you have an application which is so sensitive to a double precision
> floating point operation coming back a single precision floating point
> operation that it will cause catastrophic results I humbly submit to
> you that you shouldn't be using a desktop PC in such a casual manner.
> You are MUCH more likely to suffer from an error in any one of the
> literally millions of other pieces of that computer and software
> controlling it's operation.
>
> David Springer
> Systems Programmer
> Dell Computer Corporation
Thanks David.
As my former teacher in chemistry once pointed out, the consumption of
beer is lethal because of a special toxic substance it contains (other
than alcohol). After about one million gallons that is. Toxicity is always
a matter of dose.
Unfortunately this doesn't make Intel's response to the concerns of their
paying customers any better.
willie* chang
wrote:
> In article <caradoc-0112...@tecate.enet.net> car...@enet.net
(John Groseclose) writes:
> > In article <neep.786258206@sgi>, ne...@sgi.elec.uq.oz.au (Neep
Hazarika) wrote:
> > > >In article <3bb5bv$q...@inewssc.intel.com>,
> >
> > > >Therefore, an error will occur at a frequency of about ONCE EVERY
> > > >3900 SECONDS (9,000,000,000 / 2,307,692) OR 65 MINUTES on a 90 MHz
> > > >Pentium.
> >
> > Hmmm. I know a few doctors running their imaging software on Pentiums.
>
> So this means one pixel is wrong for every 9 billion pixels. If a typical
> image is 4000 by 6000 pixels (4 times the Kodak Photo CD resolution) then
> one out of every 300,000 images will have a wrong pixel. A speck of dust
> on a negative is a far more serious problem.
Take a look at:
http://kuhttp.cc.ukans.edu/cwis/units/IPPBR/pentium_fdiv/pentgrph.html
and you see _areas_ on a surface miscalculated, not some spot out of 9 billion
points. This is because the errors occur within certain ranges of numbers.
The previous 9 billion numbers mentioned are randomly selected but in image
rendering most pixels are correlated since that's the nature of images as well
as acoustic signals.
> > A few civil engineers doing their calculations, too.
>
> So this means the strenght of one piece out of every 9 billion pieces might be
> weaker. It should be 1.000000000 but the calculation will give 0.99999999.
> Since engineering calculations are a based on a very wide safety margin, (like
> 20% ?), the safety margin will be 19.9999999% when it should be 20%?
Not only round-offs, there're random errors as well. Even at round-offs,
some have pointed out that 2.11-2.1 gives 0 on the win calculator, a
second-digit error, and if magnified in a frame structure design, the
end effect may well be over 20% of stress tolerance for a certain
material.
> > I'd hate to see one of these "minor" errors appear in any of their projects.
>
> I suppose you would worry about the moon falling out of the sky and hitting
> you too.
With a Pentium, yes, structures can be miscalculated in regions, not just
at spots. 1 mistake can happen in 27,000 years doesn't mean it's bound to
happen at the end of that 27k-year period, it can be tomorrow for this
system, or that system, or that, or anyone of the over 5 million Pentiums,
to give one or a series of miscalculations.
> --------------------------------------------------------------
> Bruce Clarke | internet: Bruce....@ualberta.ca
> Department of Chemistry | compuserve: 70740,3135
> University of Alberta | phone voice (403) 492-5739
> Edmonton AB, T6G 2G2 | phone fax (403) 492-8231
> Canada | WWW server: www.chem.ualberta.ca
willie*
Bruce Clarke
> In article <941201...@hydra.chem.ualberta.ca>, br...@news.srv.ualberta.ca (Bruce Clarke) writes:
> |>
> |> If the FDIV did cause a failure to converge in this situation, any properly
> |> designed software would give the user an error message. There are all sorts of
> |> reasons why some software doesn't converge. Well designed software should
> |> detect the FDIV error as just another failure to converge.
>
> You are assuming that all numerical calculations are both iterative
> and quickly and easily checkable, which is just not true. In fact,
> it is easy to prove that your assumption is theoretically impossible.
Of course not all calculations are iterative. But iterative calculations are
much more likely to produce a very large number of FDIV's than noniterative
calculations. Those who argue that they are likely to hit the error because
they do 10^9 FDIV's in their calculations are most likely to be doing
iterative calculations.
My comments don't apply if someone has a vast amount of data and each data
point is processed by a non-iterative calculation. But then, they should
consider the probabily of errors in their data, whether the outcome is
affected by such errors, and whether an FDIV error is more likely and has
worse consequences.
People doing medical imaging where there is a lot of data are trying to claim
that an FDIV error will propagate and ruin an area of the image. If that is
true, then a very small amount of noise in the equipment that gathers the data
would also ruin the image. Image processing algorithms should be designed so
they extract the image and filter out the noise. I would expect that the error
produced by FDIV would be handled much like noise.
In applications of medical imaging, there is usually not just one image of the
same area. Often images from different angles are combined into a 3D image and
the consistency between different images is used to screen out noise. For an
FDIV error to get past this checking, not only does the error have to occur
(with probably of 1 in 10^9) but the erroneous point must seem like the
correct point and the various erroneous images must by chance be consistent.
That also has a very low probablity. The probably of an FDIV error giving a
result that seems correct ought to be far less probably than 1 in 10^9
> |> The only cases where the FDIV would be a real
> |> problem is when the numerical algorithms themselves are dealing with
> |> calculations of very great complexity using algorithms that are just barely
> |> stable.
>
> Consider a large matrix, with a rather poor condition number (say
> 10^6). Given IEEE DP hardware, the results will be accurate to
> 9-10 significant figures. If the FDIV bug occurs in the
> calculation of a pivot, the results will be nonsense. This is a
> significant difference on a well-known stable problem.
>
> You will ask why this should matter, because the original data are
> probably only accurate to a few significant figures anyway. The
> point is that the results will be inconsistent with the matrix,
> and invariants that would have been preserved will not be. If the
> calculation as a whole would give acceptable precision (say 2-3
> figures), under the assumption that all intermediate results are
> consistent to at least 6 figures, then a working program will give
> wrong answers.
I knew that, but my argment is not changed. I'm going to assume that the FDIV
error occurs because there are a huge number of FDIV's occurring and this is
because the matrix occurs in an iterative problem. Virtually all non-linear
problems are handled using a linear approximation which is iterated. An
incorrect solution of the linear problem which you discussed would cause a
wrong point to be generated. It is extremely unlikely that the wrong point
would be accepted as the correct answer when the convergence test was applied.
An iterative algorithm would continue with more iterations. The probably of an
FDIV error on a pivot is so small that the remaining iterations would almost
certainly not encounter the same error. They should converge to an answer that
meets the convergence condition. The result would then be just as accurate as
if the FDIV hadn't occurred. The FDIV error would usually just cause the
algorithm to iterate a few more times.
> |> Programs like this never end up in the hands of the general public. Some of my
> |> own programs do work this way. We have lots of parameters we can control to
> |> fine tune the calculations and we have to spend a lot of time tuning these
> |> parameters to get the computer to follow the curve we want to calculate. Even
> |> with my software, the actual time spent calculating a curve is short enough
> |> that an error which only occurs once an hour is unlikely to cause a problem.
>
> I find this statement almost unbelievable. One of the principal
> moans by numerical analysts about commercial and public-domain
> software is that so much of it has so little error detection.
If commercial software has so little error detection that it produces wrong
results all the time without applying any tests and warning the user, then
people should be complaining more about their software than Intel.
The kinds of calculations I do really do push the limits of what can be
calculated. Using such software requires a deep understanding of the
algorithms and sophisticated error detection techniques. The user has control
over a great many parameters and correct results are obtained only with proper
tuning. Such software never reaches the commerical market because nobody but
an expert would understand enough to tune it and get it to work.
Most of the commerical software doesn't have much error checking because the
algorithms used are very stable. But all iterative software has some sort of
convergence test. This should be sufficient to screen of FDIV errors on most
iterative calculations.
> of the main differences between high-quality software (like the
> NAG library) and poor-quality software (like Numerical Recipes) is
> that the former has immensely more error detection.
>
> Nick Maclaren,
> University of Cambridge Computer Laboratory,
I agree completely with you on the importance of error detection. Errors
caused by a bad FDIV result should be detectable in most cases by well
designed software.
--
---------------------------------------------------------------------
willie* chang
> The problem with this newsgroup is that hardly anyone seems to know anything
> about how their software actually works. I write a lot of software for
> scientific calculations on non-linear dyanamics and chaos. I also teach a
> course on numerical methods. Let me try to explain the real issues.
> The real issue here is chaos versus stability. All numerical algorithms are...
[... well written explanation of the natures of numerical approaches and chaos
deleted...]
> I really don't think the FDIV is anything to get exited about.
Maybe not, but I still find it hard to accept that
x*(1/x) is not 1
and
x-(x/y)*y is not 0.
Or should I do a human decision to round off myself when a machine gives me
0.9999961782094 and the like?
Or when I see x-(x/y)*y=256 I interpret this '256' as 1 myself?
Or should I use those 'results' if they're in my favors, otherwise, use a hand
calculator? Better yet, bring a Pentium laptop to purchase a new car and
show the sales that the dealer mark-up is gladly accepted and calculate
that fat 10% mark-up by
$MSRP * 10% * (x*(1/x))^999999999999 to bring it down to 0? And if they
don't agree, show them the wonderful essay of chaos and stability in numerical
approaches to convince them that there's nothing incorrect? :)
> ---------------------------------------------------------------------
> Bruce Clarke | internet: Bruce....@ualberta.ca
> Department of Chemistry | compuserve: 70740,3135
> University of Alberta | phone voice (403) 492-5739
> Edmonton AB, T6G 2G2 | phone fax (403) 492-8231
> Canada | WWW server: www.chem.ualberta.ca
willie*
Tom Nagy
In article 02129406...@glenn-slip42.nmt.edu, cha...@nmt.edu (willie* chang) writes:
->Or when I see x-(x/y)*y=256 I interpret this '256' as 1 myself?
^^^
Wouldn't do that if I were you.
Tom
Email to me will bounce.
Mel Martinez
>
> I think all this fuss is from people who know absolutely nothing about how
> their software actually works. The only cases where the FDIV would be a real
> problem is when the numerical algorithms themselves are dealing with
> calculations of very great complexity using algorithms that are just barely
> stable.
>
Consider something so 'simple' as a series of rotations. I have written
(some time ago) a program that simulates rotating a payload through pitch,
yaw and roll maneuvers, calculating the right ascention and declination of
payload axis and the roll orientation relative to celestial north. This
program runs exact on macs, sparcs and '486s, etc., but not on a Pentium
because it absolutely requires at least double precision and yes, does
require division. This set of calculations simply cannot be done in
single precision without serious re-writing of the code, if it can be
done. The problem is that even the tiniest errors propagate and expand
through subsequent rotations, quickly becoming unacceptable. You can see
this for your self by simply rotating a pencil first along one axis (it's
length) and then along another (let's say perpendicular to the printing).
A tiny variance in the first rotation can result in a dramatic error in
the final orientation of the pencil. Try this for several subsequent
maneuvers!
A correllating routine takes the desired orientation and calculates the
maneuvers necessary to get there. These have to reach closure in order
for us to fly. The pentium can not be relied on to give us closure on
this calculation.
Considering how much it costs to develop and launch even the relatively
'inexpensive' payloads I deal with, errors such as this are totally
unacceptable.
This sort of calculation is not very complex (it's just euler angle matrix
multiplication) and the algorythms are, indeed very stable. There is
nothing new or exotic involved.
> Programs like this never end up in the hands of the general public. Some of my
Ridiculous.
> own programs do work this way. We have lots of parameters we can control to
> fine tune the calculations and we have to spend a lot of time tuning these
> parameters to get the computer to follow the curve we want to calculate. Even
> with my software, the actual time spent calculating a curve is short enough
> that an error which only occurs once an hour is unlikely to cause a problem.
>
> I really don't think the FDIV is anything to get exited about.
>
Not all calculations are iteratively arrived at with convergence testing
possible. You need to consider the exact deterministic case. If 1/x is
wrong, all deterministic calculations reliant on 1/x are simply, wrong.
For many calculations, 14 bits of precision is insufficient to result in
anything but wrong answers.
Cheers,
Mel Martinez
The Johns Hopkins University
Dept. of Physics
m...@pha.jhu.edu
Marc A. Murison
>Assuming this is a legitimate posting of which ther is
>a doubt as I cannot finger you or ping the news server
>and mail to the sender bounces. However, I will assume
>it is for the moment.
To help bury this one: the same exact text is posted on the intel www server
(try http://www.intel.com). Further, I talked with one of the engineers who
was directly involved in editing Grove's text into the form we all saw.
Apparently, the rough draft was considered way too "long-winded." In
response to a question from me, the engineer said Grove wrote it, and he
(Grove) personally read and approved the edited version before it was sent
out. There was some problem getting a machine at intel to send it out on
that Sunday, hence the lack of "intel.com" in the address of the poster.
(Murphy's Law strikes again?) So it really does appear to be legit, and we
can stop wasting time on this one.
---------------------------------------------------------------------
| Marc A. Murison | Smithsonian Astrophysical Observatory |
| mur...@cfa.harvard.edu | 60 Garden Street, MS 63 |
| (617) 495-7079 | Cambridge, MA 02138 |
---------------------------------------------------------------------
Chris Umbricht, M.D.
Valentin Richter, ric...@informatik.uni-muenchen.de writes:
>As my former teacher in chemistry once pointed out, the consumption of
beer is lethal because of a special toxic substance it contains (other
than alcohol). After about one million gallons that is. Toxicity is
always a matter of dose.<
I think he was referring to trace amounts of Cobalt in an antifoaming
additive... this led to congestive heart failure after a few decades of
regular beer drinking. I'll leave it as an exercise for the reader to
decide if this was a significant cause of death in the german population.
Note: the additive WAS banned.
The difference, of course, is that this toxicity took quite a while to
develop. This does not appear to be the case with the P5 depending on
what you are doing with it....
David Gutierrez
wrote:
> It just goes to prove, rewriting the laws of Mathematics only requires
> a 80% market share, not so much a BS, MS, or PhD.
Well, you need some BS...
--
David Gutierrez
d...@biomath.mda.uth.tmc.edu
"Only fools are positive." - Moe Howard
Peter Choi
epit...@csc.com (Ernie Pittarelli ) wrote:
>
>> In article <caradoc-0112...@tecate.enet.net>
>car...@enet.net (John Groseclose) writes:
>> > In article <neep.786258206@sgi>,
>ne...@sgi.elec.uq.oz.au (Neep Hazarika) wrote:
>> > > >In article <3bb5bv$q...@inewssc.intel.com>,
>> >
>> > > >Therefore, an error will occur at a frequency of
>about ONCE EVERY
>> > > >3900 SECONDS (9,000,000,000 / 2,307,692) OR 65
>MINUTES on a 90 MHz
>> > > >Pentium.
>> >
>> > Hmmm. I know a few doctors running their imaging
>software on Pentiums.
>>
>> So this means one pixel is wrong for every 9 billion
>pixels. If a typical
>> image is 4000 by 6000 pixels (4 times the Kodak Photo
>CD resolution) then
>> one out of every 300,000 images will have a wrong
>pixel. A speck of dust
>> on a negative is a far more serious problem.
>>
>Excuse me?! Have you done any image processing lately?
> Very few people are using images that are 1-bit deep!
> Try multiplying 4000x6000x24 bits to get a truecolor
>image and see if you come up with less then 1:300,000
>next time.
>
>Ernie P.
>epit...@csc.com
>----------------------------------------------
>These opinions are mine and not my employers.
okay, we kinda know what the heck is going on with intel. what
are we, what are people gonna do now with an untrustable
computer? what about those with math intensive applications?
use a 486? sit around til they "hand" out new chips?
Jerry Fontaine
Actually I was told by one of my intern friends from Intel
that there are in fact *tons* of bugs with Petium chip (just as there
were with the 80x86's), but it was top-secret classified, if you tell they
may take legal action.
Sometime last summer while interning at Intel, a student had
come across some proprietary information incrimintating the Pentium chip
(essentially, a pretty huge bug list). After the rumor circulated through
the ranks, management at Intel went into a flurry. They called
departmental meetings and threatened those propagating information
with legal action. Many of the students protested because the felt
the public should be aware of the known (but unattended) flaws inherent
in an already released chip.
I salute those with the courage to stand up against Big Brother
Intel. They may not be working for them now, but they were brave and
understood the power of trust over the dollar.
Bruce Hoult
> Looks like the Big Brother is dictating inside his giant corp like this:
> "Each of you is a single cell in the great body of the State. And today,
> that great body has purged itself of parasites. We have triumphed over the
> unprincipled dissemination of facts. The thugs and wreckers have been cast
> out. Let each and every cell rejoice! For today we celebrate the first
> glorious anniversary of the Information Purification Directive. We have
> created, for the first time in all history, a garden of pure ideology where
> each worker may bloom secure from the pests purveying contradictory and
> confusing truths. Our unification of thought is more powerful a weapon than
> any fleet or army on earth. We are one people. With one will. One
> resolve. One cause. Our enemies shall talk themselves to death, and we
> will bury them with their own confusion. We shall prevail."
Gee. And when I saw that ad ten years ago, I thought it was talking about
IBM. And now they're the good guys, replacing the Pentagram chips they've
sold, and helping Apple with PowerPC.
So now we're at war with Eurasia and at peace with Eastasia. Or the reverse.
Or something.
But it was all right, everything was all right, the struggle was finished. He
had won the victory over himself. He loved Big Blue.
Frank Lofaro
>
>If the doctors are using Pentiums for that type of thing, why not just go
>back to an 80486/DX4 100 until the debugged pentiums come out? I mean
>sure, it might take a few more minutes to process...but it might save a
>patient down the line. I'd say a few seconds now is worth an eternity in
>hell for mal-practice, wouldn't you?
>
Maybe people should use an Nx586, by NexGen.
Intel Inside seems to mean Bug Inside with the Pentium.
I can understand bugs, but not telling anyone that is not a professional
number cruncher that they are stuck with a broken product, and if they
want something that works, that they have to pay full price for a new one,
and not get any credit for the old. Heck, they should give free refunds,
IMO, but leaving people with a chip that is worth nothing to them is wrong.
VERY WRONG.
Intel, that sucks!
I used to be a real pro-Intel person, telling people to buy genuine Intel.
But I no longer feel comfortable with the idea of buying a processor from
them or recommending them to my friends.
[Other than the FDIV bug (much worse than just the 9th decimal digit, at
times up to the 4th digit!), NexGen Nx586 seems to be a better product.
It has more internal cache, etc, etc.]
I might buy/recommend Intel chips other than CPUs, if they were cheap.
(money-wise, not quality wise).
Phil S. Fair
>> tho...@orion.oac.uci.edu (Trangdaithi Hoang) writes:
>>
>> [snip...]
>>
>> >with a frequency of about ONCE EVERY 3510 SECONDS OR 58.5 MINUTES.
In article <3bl9qn$e...@uudell.us.dell.com>, spri...@dellgate.us.dell.com (David Springer) writes:
>> Forgive my ignorance, but what application do you use that manages to
>> generate 18 billion meaningful floating point input operands and
>> utilize the 9 billion double precision dividends once every 39 clock
>> cycles ? Maybe I'm just naive but isn't there a *lot* of other stuff
>> that has to happen besides the divide in order to do something with
>> the result ?
[snip again...]
I believe one application that some one wrote (I don't remember who) that
manages to generate 18 billion meaningful floating point input operands
and utilize the 9 billion double precision dividends once every 39 clock
cycles did the experiment exactly as Intel described. They took random
numbers and did floating point divides. The rate of errors that they
reported was approximately 2 an hour. But then again, who is
counting...8-)
Phil p...@shell.com
Phil S. Fair
>> [snip...]
>> code in the firmware, the operating system, or the application. If
>> you have an application which is so sensitive to a double precision
>> floating point operation coming back a single precision floating point
>> operation that it will cause catastrophic results I humbly submit to
>> you that you shouldn't be using a desktop PC in such a casual manner.
>> You are MUCH more likely to suffer from an error in any one of the
>> literally millions of other pieces of that computer and software
>> controlling it's operation.
>>
>> David Springer
>> Systems Programmer
>> Dell Computer Corporation
>>
>> employer>
>>
And I humbly submit that Intel, or Dell as a Pentium distributer, should
truthfully advertise:
PENTIUMS - Computer for game playing, word processing, and other trivial
tasks. CAUTION: Serious computer users (including mathemeticians,
scientists, engineers, and people who might want the correct answers)
use a different machine like maybe an PC 8088/87, PC 80286/87,
PC 80386/87, or PC 80486DX.
These all meet my floating point double precision requirements8-).
Does Intel really want to compete with Nintendo for market share rather
than HP, SUN, Digital, IBM...?
Phil p...@shell.com
<These are person opinions and do not represent the opinions of my
employer, too.>
Mark Schmidt
>I am personally astonished at how
>poorly they have handled this whole situation.
>The bottom line is that the integrity
>of the chip and any computer it is in has been shattered.
>P.S. Much has been said about the ramifications
>of this "bug" in intensive calculations, but
>amongst it all I haven't seen anybody
>point out that algorithms which converge on
>solutions will probably be unaffected.
the final solution may be unaffected, but the algorithms
will take more steps to reach the solution.
i have seen a few posts here which documented this.
Brent T Rowe
: How did they get 27000 years???
: We would have to be doing one FDIV every 122 seconds to get the answer of
: once every 27,000 years.
: F(845640560000) = (.9999999999)^(1/122 * 845640560000) = 0.5
: DEAR INTEL-- WHAT ASSUMPTIONS DID YOU USE WHEN CALCULATING THIS 27000 YEAR
: EXPECTED TIME BEFORE FAILURE???????
They were using a pentium to do the calculations (of course).
Sinan Karasu
Bruce Clarke <Bruce....@ualberta.ca> wrote:
[.....stuff deleted....]
>People doing medical imaging where there is a lot of data are trying to claim
>that an FDIV error will propagate and ruin an area of the image. If that is
>true, then a very small amount of noise in the equipment that gathers the data
>would also ruin the image. Image processing algorithms should be designed so
Wrong. Completeley wrong. The false area appearing would happen in the case
when you "know" that the noise level and gradient is low. If the noise
level is high then this would not happen or be inconsequential.
>they extract the image and filter out the noise. I would expect that the error
>produced by FDIV would be handled much like noise.
By the time you have done morphological operations on your gray-scale
processed image, that area would appear like signal.
>
>In applications of medical imaging, there is usually not just one image of the
>same area. Often images from different angles are combined into a 3D image and
>the consistency between different images is used to screen out noise. For an
Not if you are doing research in monocular vision. Therefore this
argument has absolutely no bearing on the problem and is misleading.It is
a different subject.
>FDIV error to get past this checking, not only does the error have to occur
>(with probably of 1 in 10^9) but the erroneous point must seem like the
>correct point and the various erroneous images must by chance be consistent.
>That also has a very low probablity. The probably of an FDIV error giving a
>result that seems correct ought to be far less probably than 1 in 10^9
[....deleted....]
>I knew that, but my argment is not changed. I'm going to assume that the FDIV
^^^^^^^^^^^
Good. I said that once....
>error occurs because there are a huge number of FDIV's occurring and this is
>because the matrix occurs in an iterative problem. Virtually all non-linear
This is exactly what he was saying that it was not. An iterative problem.....
[....deleted....]
>
>If commercial software has so little error detection that it produces wrong
>results all the time without applying any tests and warning the user, then
>people should be complaining more about their software than Intel.
>
>The kinds of calculations I do really do push the limits of what can be
>calculated. Using such software requires a deep understanding of the
>algorithms and sophisticated error detection techniques. The user has control
No it does not.
Are you saying that if I buy a pentium and
try to calculate bessel functions from the raw definitions and therefore
end up with some ungodly division then I am not to fit to use pentium?
(Granted, in this case the result would be garbage on any processor.)
Are you saying that if the poor student is trying to experiment , that
is not his right to do so because he does not understand the workings
of the processor and the "such software"?
Are you saying that he should not be using any such algorithms as numerical
recipes on the pentium?
I do not think that is what you are saying. At least I hope not...
>over a great many parameters and correct results are obtained only with proper
>tuning. Such software never reaches the commerical market because nobody but
>an expert would understand enough to tune it and get it to work.
>
>Most of the commerical software doesn't have much error checking because the
>algorithms used are very stable. But all iterative software has some sort of
>convergence test. This should be sufficient to screen of FDIV errors on most
>iterative calculations.
>
>> of the main differences between high-quality software (like the
>> NAG library) and poor-quality software (like Numerical Recipes) is
>> that the former has immensely more error detection.
>>
>> Nick Maclaren,
>> University of Cambridge Computer Laboratory,
>
>I agree completely with you on the importance of error detection. Errors
>caused by a bad FDIV result should be detectable in most cases by well
>designed software.
Are you saying that pentiums should only be sold to people
who understand the convergence/error propagation properties
of numerical algorithms?
There is such a thing as freshmen and sophomores who take great
pride in discovering these things for themselves.
Food for thought.
PS: Last time I said food for thought I got an e-mail from
a person who said that he hopes that I choke on it.
Has anyone else gotten such an e-mail ? His last
name starts with P.
Ed Hall
This might, indeed, be the case. On the other hand, remember that iX86
floating-point units do their calculations in an extended 80-bit format,
converting back to 64-bit or 32-bit format only when results are stored.
This can cause a difference in highly iterative calculations between
iX86, including Pentia, and some other FPU's. That's why comparison
with a 486 doing the same calculation can provide much stronger
evidence than one run on other hardware, since its basic math
operations are the same as the Pentium's (except that the divide bug
is missing).
I've done highly iterative algorithms on Sparc's and '486's with
somewhat different results due to the excess precision of the latter.
On the other hand, one of the things that bothers me most about the bug
with respect to some iterative algorithms is that the value of C/x is no
longer monotonic. This can lead to failure to converge, convergence to
a local minimum, differences in time to convergence, and other
anomalies, depending upon the algorithm involved. (Or, the error is
wiped out by further iteration, probably the most likely event but
by no means the only outcome--"It Depends...")
-Ed Hall
edh...@rand.org
Jason Untulis
(willie* chang) wrote:
> Not only round-offs, there're random errors as well. Even at round-offs,
> some have pointed out that 2.11-2.1 gives 0 on the win calculator, a
> second-digit error, and if magnified in a frame structure design, the
> end effect may well be over 20% of stress tolerance for a certain
> material.
Not that I am a Wintel fan at all, but the bug in the win calculator,
according to Brian Livingston's column in Infoworld (who may be getting
his data from elsewhere), is a display problem. The number is computed
correctly and will propagate correctly, but it *looks* wrong.
-------
#include <std/disclaimer> (C) 1994. All rights reserved.
Jason Untulis
untulis@ (netcom.com) (tower.tandem.com)
untuli...@tandem.com, ja...@hplcau.hpl.hp.com
"You don't want to upset the dinosaurs, do you?" -- CompuServe ad
willie* chang
> In article <941201...@hydra.chem.ualberta.ca>, Bruce....@ualberta.ca
> wrote:
>
> > The problem with this newsgroup is that hardly anyone seems to know anything
> > about how their software actually works. I write a lot of software for
> > scientific calculations on non-linear dyanamics and chaos. I also teach a
> > course on numerical methods. Let me try to explain the real issues.
> > The real issue here is chaos versus stability. All numerical
algorithms are...
>
> [... well written explanation of the natures of numerical approaches and chaos
> deleted...]
>
> > I really don't think the FDIV is anything to get exited about.
>
> Maybe not, but I still find it hard to accept that
>
> x*(1/x) is not 1
> and
> x-(x/y)*y is not 0.
>
> Or should I do a human decision to round off myself when a machine gives me
> 0.9999961782094 and the like?
> Or when I see x-(x/y)*y=256 I interpret this '256' as 1 myself?
I mean 0. :)
willie*
Greg Thoman
>
>Not that I am a Wintel fan at all, but the bug in the win calculator,
>according to Brian Livingston's column in Infoworld (who may be getting
>his data from elsewhere), is a display problem. The number is computed
>correctly and will propagate correctly, but it *looks* wrong.
I've just checked and this is true. The Windows calculator
doesn't do the math wrong, it apparently just displays small non-zero
results incorrectly. Here's a sample:
Computation: Displayed Result:
3.11-3.1 0.00
*42 0.42
Thus, the correct answer (0.01) of the first computation was
used when I told it to multiply the previous answer by 42. Thus, this
will not produce error propagation problems unless you happen to
write down or key in one of the incorrectly displayed answers for
further re-use.
Contrast this with the Pentium FDIV bug, in which the computed
result is actually incorrect (sometimes with only 4 base-10 digits
correct) and the error will grow or decay in significance with further
use of the result, depending on the nature of the computations.
Since I do circuit simulations (these are capable of
accumulating errors and giving strange results), I'm glad I don't have
a Pentium and thus one more error source to worry about (besides all
the usual ones).
--
Greg Thoman: The opinions expressed herein are mine alone, and I am
solely irresponsible for them.
Yan Lee
: Actually I was told by one of my intern friends from Intel
This is very interesting stuff. However, I bet this stuff goes around
not only in intel, but also in other big chip makers like IBM or
Motorola.
I am surprised by intel's PR. I expect much better response from such a
big and reputable company. Look at the makers of Tylenol, when somebody
poisoned one tablet and Tylenol recalled ALL of their drugs from the
whole country, which could have costs millions of dollars to do. This
move was not only good for the general public, but also for themselves
as people continued to still buy their products. I supposed it is a
little different that lives were at stake. However, lives could be at
stake indirectly if somebody is using the pentium chips for some sort of
design of a safety deivce. Well, I don't know...they shoudln't have
come out with the "That's too bad" attitude.
Tony