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.