Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Intel Corporation (INTC) -- Ignore unavailable to you. Want to Upgrade?

To: Scumbria who wrote (106733)	8/2/2000 10:15:26 AM
From: Windsock	Read Replies (1) \| Respond to of 186894

Scumbria - Re:"Here are a few facts:" And here is another fact: Intel has introduced a part that beats anything offered by the competition. Just like Pavlov's dogs at the ring of the bell, this causes the Intel haters to ignite the flaming keyboards. The reaction is as predictable as the rising of the sun in the East every morning.

To: Scumbria who wrote (106733)	8/2/2000 3:58:32 PM
From: pgerassi	Read Replies (2) \| Respond to of 186894

Dear Intel Shareholders: The best explanation for the 2 failures of a 1133 MHz P3 from working at specified speed is one that gives the benefit of the doubt to both Intel, Tom, and Kyle. The CPU passed validation yet failed later. All engineering types should know the typical failure rate versus time curve that almost all products share. This is the one where the curve after appropriate scaling in time, looks like the profile of the inside of a bathtub. There are a lot of failures occurring in the first few percent of the mean lifetime. For some parts, this can be as low as a few parts per million. At time zero, it is at infinity covering those parts that never work. During most of the remaining life, the failure rate is very low. As the part approaches the mean lifetime, the rate begins to go up on an exponential curve. This is the basic curve to look for an explanation. Evidently, Intel did not cover in testing of this part over a sufficient time to allow for all the failures the occur in the first part of the curve. This is the standard practice. Why? It may be that there is a component to the curve that has a low spike just after the original quick fall to low levels. This spike does not stop the processor from working but, stops it from working at speed. Given the short time Intel had to qualify the new stepping, it could have been missed because it did not happen before this stepping and they did not know to look for it or some other unusual failure mode. Perhaps the accelerated aging process that Intel uses, does not accelerate this particular type of failure. This is probably the type of error that allows Intel to validate a processor that later fails. As far as they knew, the stepping and that particular CPU was ok. It then was shipped. During the time it spent in transit or plugged into the first motherboard, it failed the stressful tests placed on it. From then on, it is a slower CPU but not dead. Both Tom and Kyle then report difficulties noted. The reporting styles might cause some on this thread to complain but, this is information that the shareholders should know. IBM and DELL may deal with this additional spike by increasing the Burn In Time to really push past this spike and that is the reason for the long ship times. In the old days, every system was burned in to get rid of these "Baby" failures. Due to the extremely high reliability of current components all around, people have come to expect a single Baby failure as a sign of impeding doom. In IBM's and Dell's defense, this is a typical way to unmask these types of failures. However, if there are more spikes later in the curve, this could become disasterous for OEMs as the failures must be fixed in the field at high expense. This is what would worry the typical manager (and I) about this CPU. The uncoupling of the models from reality will cause even more problems in the future as this allowed both AMD and Intel to remove these problems by simulation. This may be harder to fix. The short lead times between a new stepping and shipping of it, is the real cause of this problem. AMD got burned during Q4 1998 due to a similar problem that showed up during internal testing. Now competitive pressures may be causing Intel to hit these as well. There are some solutions to this problem. 1) Blame the messenger. The problem with this is that sooner or later this will come back to haunt you. Remember, this is the solution Intel tried with the FDIV problem. You all know how that worked. 2) Work around the problem. Acknowledge it but, claim it is fixed by extensive burn in time. Add expense to the retail price of working CPUs and hope that no more spikes occur later. 3) Recall all CPUs. Acknowledge that you have a problem. Work the problem to see if, it can be solved. This takes a short term hit but may produce many dividends later. 4) Delay future shipments. Stop OEMs from shipping to customers by claiming supply problems of an unrelated component. Stay silent to public. Work like hell to fix. This is their most likely course based on past experience. Paul, Elmer, and others seem to want choice 1. This would be very bad. Choice 3 is the best policy long term. The longer they delay in implementing it, the less will be thought of them although, choice 4 allows them to save face if, and its a big if, they are able to fix it within a short amount of time, say 3 weeks or so. Pete