VOGONS


First post, by trodas

User metadata
Rank Newbie
Rank
Newbie

http://www.bleedinedge.com/forum/showthread.p … for-SuperPi-32M

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:

Super_Pi_12h_28min_per_loop.jpg

Super_Pi_17h_59min_per_loop.jpg

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:

Super_Pi_crashed_when_run_without_caches.png

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 80% at the time of the posting - 3.9.), 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. Anyone can explain me this or suggest somethig that will slow SuperPi down w/o the crash? 😐

It is dangerous to be right in matters on which the established authorities are wrong. Voltaire
I believe that all the people who stand to profit by a war and who help provoke it should be shot on the first day it starts... Hemingway

Reply 1 of 4, by idspispopd

User metadata
Rank Oldbie
Rank
Oldbie

Might this be the row hammer effect? I suppose combining turning off caches and using a memory intense program like Super PI should increase the probability of an error.

Reply 3 of 4, by trodas

User metadata
Rank Newbie
Rank
Newbie

idspispopd -

memory intense program like Super PI should increase the probability of an error

I stressed the memory on each of the there completely stable systems by Prime95 and special memory settings for torture test (min. FFT size 1792...) and memory are not faulty. So no... it cannot be, that there is a fault in the ram access, due to being "too frequent" thanks for caches being disabled.
I wish it can be somehow "explained away", but it is not that easy, as other programs are running fine. For example my slow Aquamark run is running since 13.8. and that is w/o caches and IT DID NOT CRASH! (yet)

But it was an interesting idea never the less 😀 More brainstorming?

alexanrs -

Could it be SuperPi itself having time counters that overflow and make it crash?

If there are dynamic timers, that somehow calculate based on known CPU IPC, clock and memory speed the assumed run time and when the deviating is too big (like 2 - 3 times the assumed time), then it could explain this away... but I would expect some sort of message rather that crash.

I tested on there oldtimers machines:
PCchips M810LR (SIS 730) with 11x100MHz AXP Barton core, SDRAMs 3-3-3-6 ( http://trodas.wz.cz/index.php?act=ST&f=16&t=337 )
Jetway V266B (KT266A) with 5x100 AXP-M cpu, DDR 2-2-2-5 ( http://trodas.wz.cz/index.php?act=ST&f=16&t=355 )
MSI PM8M3-V (VIA P4M800) with 17x200 Pentium 4 cpu, DDR 2-3-2-5 ( http://www.badcaps.net/forum/showthread.php?t=26130 )

All these machines are precisely (ALL CAPS!) recapped with quality caps, perfectly stable (can run SuperPi 32M all days long w/o an error) and underclocked to achieve absolute stability for slow-down reasons. Yet it is impossible to do a 12+ h run SuperPi 32M test on them by killing the caches.

I admit that it serve a little practical purpose, but it is still puzzling me, why this is happening. I can and I will make the HWbot achievement (five 12+ h SuperPi 32M runs need) by other CPU's, that is not the problem. I just want to know why this is happening. If anyone come with some test that I can perform, then the M810LR is free to do some work and overnight is possible to utilize the MSI PM8M3-V ...

It is dangerous to be right in matters on which the established authorities are wrong. Voltaire
I believe that all the people who stand to profit by a war and who help provoke it should be shot on the first day it starts... Hemingway

Reply 4 of 4, by trodas

User metadata
Rank Newbie
Rank
Newbie

Reason for the crashing found and confirmed: SuperPi v1.5 and v1.6 (the later is just copycat version of the older mod1.5 for XS) fail when the time is over 24h for 32M test, quite possibly for ANY test:
http://forum.hwbot.org/showthread.php?t=141901&page=4

Since it was confirmed by many and there is no record of over 24h run of SuperPi EVER made on HWbot, therefore I suggest a fix/patch to fix this problem. A good example is the AMD K5 PR75 CPU. Even at 90MHz it canot finish the 32M run in time... so for benching old computers it is necessary to have a fix for this.

I seems to have a talent for finding bugs everywhere. I did not do it on purpose, I just stumble on them... 🙁 I wish I do not, but...

Test:
Super_Pi_32_M_24h_failure.jpg

...a hour later:
Super_Pi_32_M_failed_24h.png

SuperPi v1.6 Techpowerup mod crash at 24h mark for 32M test too:

Super_Pi_1_6_24h_crash.jpg

It is dangerous to be right in matters on which the established authorities are wrong. Voltaire
I believe that all the people who stand to profit by a war and who help provoke it should be shot on the first day it starts... Hemingway