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: semiconeng who wrote (106999)	8/4/2000 3:39:23 PM
From: pgerassi	Read Replies (4) \| Respond to of 186894

Semiconeng: If you can not understand that the same exact CPU can be underclocked like one can be overclocked (you insinuated that by your 800 MHz on a different process crack), then you are no engineer in the semiconductor field (either that or the quality of engineering has declined dramatically at Intel). Since I do not believe that anyone could miss this simple truth, I believe that you do not want to face the truth that there now exists two reports of 1133 P3s from working at rated speed. Explaining away the use of a benchmark that seems to point out an instability in a CPU under high load conditions (Intel uses a different program (like BurnP6) and may not stress the same areas that the Prime95 benchmark does). That it can occur is why most submit samples to reviewers under NDAs to verify usability due to many different people use different methods to test a CPU. Remember, the FDIV bug was found by a person interested in numeralogy (the study of really big numbers). The flak Intel took was for their response, not the fact that it was there. People like their computers to be stable and predictable. When they hand out incorrect answers or do other equally creative things not programmed to do, people call the repairman to fix it. If it is under warranty (like most of the CPUs with FDIV), people expect Intel to fix it, period (most did not turn in their CPUs for replacement, it was the idea that an obviously bad CPU could be given to somebody and you would be "Stuck" with it). Thus most of the outroar here was not the fact that 2 CPUs were marginal and wound up in reviewers hands as "Engineering Samples", it was the fact that they were given to two reviewers as "Production" CPUs. Engineering samples are allowed to not work in certain situations, production CPUs should never show these problems without immediate replacement, "Sorry that this one was bad" response, and never, ever be given to reviewers at all during a launch. Where were you during Intel's FDIV fiasco? Were you one who said "It must be the software", "It can not be our (Intel) CPU", or "It would have never been missed by Intel, so the reviewer must be wrong"? You locked on to the last statement with Tom Pabst. Then, you used the first two with Kyle (HOCP). Why does there need to be a "Microcode Patch" in the first place? Could Intel have found different erratum(s) (bug(s)) in their new CPU bin? How many fixes in that patch are there? Granted, in the old days, Intel could spend months in sending revisions of a new speed stepping until they have not found any bug for a month, ramp production, verify that production CPUs are bug free, and then finally launch. Most of these problems would be fixed long before the public ever saw the CPU (FDIV being an exception to this rule). Much of the Intel reputation seems to be it could afford to take the time required to do it right. Now that is no longer true, and Intel is being brought into the same light as everyone else who needed to compete. AMD is trying the old Intel way, short term pain for long term gain. Pete