If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

And to make it even worse, System 3 is about to finish its run and even though it is the most modern 486 EVER, it is a little slower than System 2: it is PCI (instead of the good old VLB ) based and it has an Enh. Am486DX5-160 in L1-WriteBack mode with 512 kB (instead of 1 MB) of WriteBack L2 Cache, 64 MB of 50 ns EDO (instead of FastPage) memory running at 40 MHz and a 120 GB IBM Deskstar 120GXP at UDMA-66 (instead of PIO Mode 5)!!!

Comment

This thread made me wonder, if I can slow-down SuperPi significantly, to produce long computing times on relatively modern hardware, like AthlonXP CPU's. Most these old board can disable L1 and L2 caches, some even the SSE instructions support and even that disabling all but L1 does not affect the performance much, disabling L1 is "super-killer" of performance.

So that makes me wonder, how slow it will go on the SuperPi 32M test.

For the reference, all these machines can do SuperPi 32M w/o fail or crash or any other problems, all the computers have replaced their original bad caps to good ones and all these computers are 100% stable and I can run on th SuperPi 32M tests repeatedly w/o any trouble... BUT!

Here we come. I got starting scores 12h 28min per loop, or even 17h 59min per loop:

The later would produce (18hx24) a 432h long benchmark (18 days), and that is 1100MHz AXP using 256MB SDRAM (PCchips M810LR mobo).

However, and that is where things get really bad, it always crash. Sooner or later it crash on any machine with disabled L1 cache in bios I run it. A good example is P4 3.4GHz CPU that fail w/o caches too:

I would once again stress, that the machines are completely stable, there is no way that the error is hardware related. Not when it happen like 10x times.

...

So I stopped trying the cache and I added CPU stressing (for example latest CPU-Z v1.73) that run at high priority, while SuperPi do run at low priority, causing it to slow-down to point that the whole calculation of 32M will took about 18 to 24h, depending on settings of the priority and stuff.

Now imagine my surprise, when this also started and continued crashing. Numerous attepmts did not yield one SINGLE result. I'm "a bit" surprised and I cannot explain this behaviour. Normally systems w/o cache works just deadly slow (Aquamark3 is running on Duron 750 at 30x7.5 without caches since 13.8. and it is hardly in the half at the time of the posting - 27.8.), but works. No crashes or other problems (unless I click too much, one have to be carefull, even mouse have like 10sec lag when moved in Aquamark 3 ) happen, so my question is deadly simple - anyone have any idea, why this is happening?

Ano no, please don't say stability. These boards ARE reliable and stable. They can run SuperPi 32M each day releatedly, but not w/o caches or when slowed down, witch is weird at least.