-----Original Message-----
From: George Woltman <[EMAIL PROTECTED]>
>Hi,
>
>At 12:24 AM 1/13/99 -0800, Leu Enterprises Unlimited wrote:
>>On one CPU, after two days worth of burn-in, the time required to
>>complete 100 iterations on the stock number went down, as I would
expect.
>>
>>On a second CPU, the time actually *increased*. From 1 day, 18 hours,
>>and 55 minutes, to 1d 19h 13m!
>
>I'd be surprised if burning in had an effect on iteration times.
>More likely, 100 iterations is not enough to get a truly accurate
>timing.
<snip>
Very true. All things being equal, execution timings are governed
solely by the clock speed. For a fixed clock and bus multiplier, a chip
neither speeds up nor slows down during its life. The *maximum* speed a
given chip runs at may change slightly, but any timing differences noted
in mprime or Prime95 are likely the result of either different system
and memory loadings, or timing roundoff errors.
>>If anyone knowledgeable would care to comment about mprime's
suitability
>>for Q.A.
>
>mprime is great for QA. It generates heat (by FPU use) and tons of
>memory accesses. If there are any hardware problems there, they are
likely
>to show up in an extended torture test.
>
Prime95 and mprime both provide excellent QA capability. A better test,
however, is to run both m/prime95 and a second FPU and memory intensive
application simultaneously.
<snip>
>Best regards,
>George
Regards,
Ethan
