Rogier Wolff wrote:
> Dg B wrote:
> > problem. If the CPU was not designed to handle this kind of speed, then
> > Intel should really go down to the floor of their manufacturing plants,
> > because they are building chips that are definitely outstripping the
> > "...operating limits..." as stated by the design engineers. Then again,
> > maybe it is not the designers who are making these decisions...
>
> The 300MHz components were taken straight out of the 450MHz P-II production
> line, so maybe they WERE designed for this.
This is woolly logic. The parts taken from near the edge of a wafer generally
have a higher defect rate, and those that work don't work so well. Pollution
tends to be higher near the edge, leading to the higher defect rate. The
optical printing system tend to be a little fuzzier near the edge, leading to
the poorer performance. There will generally be significant speed, and
possibly current consumption, differences between these and the cleaner parts
from near the middle of the wafer. Some ICs available in various speed ratings
are due to concurrent production of older and newer (possibly shrunk) parts.
More commonly the slower parts are from around the edge of the same wafers
that produced the faster parts.
If there are plenty of fast parts but only strong demand for slower ones,
makers are known to stamp high grade parts as slower ones, but don't count on
it.
> On the other hand, Intel knows a lot more about the devices than you
> and I.
I sometimes think this might be woolly logic too!
> If they have a batch that does not tolerate 2.2V Core, and with 2.0V
> Core it may only achieve 400MHz. But with tolerances on input voltage
> and allowed case temp, it may only achieve 325MHz. So if you "quickly"
> test it it may seem to work just fine at 2.2V and 450MHz, but in fact
> you're wearing your chip down a lot faster than intended, and you're
> likely to hit a limit under some "extreme" circumstances at some time
> in teh future.
>
> But then again, 450 MHz may just work fine for all eternity.
>
> While debugging the hang problem, I find it best to try to remove the
> "overclocking" variable from the process...
Steve
--
=- To unsubscribe, email [EMAIL PROTECTED] with the -=
=- body of "unsubscribe linux-abit". -=
