Rundown to SuperPrime 1.0Final : Need your help!

[FrogBite]

here

[KTE]

GHZ: the error you were getting is typical of RAM instability/fault. I use this app to test my RAM, far better than 32M/2k6. Is your RAM perfect with Memtest?

SuperPrime catches RAM instability very quickly.

[death]

really like this keep up the good work

[KiD0M4N]

here

Thanks for the dump FrogBite.

I ran it through the benchmark and it recognized the settings perfectly. Even though the dump was from 1.38 Cpuz (thanks againt Franck :P)



(ignore that error in timing measurement, will fix that small little in next version.)

GHZ: the error you were getting is typical of RAM instability/fault. I use this app to test my RAM, far better than 32M/2k6. Is your RAM perfect with Memtest?

SuperPrime catches RAM instability very quickly.

Glad to know that. But I would love to catch the error and show it as a exception rather than as a system error. Am working on that now

[KTE]

It would be good but hefty work Karan. Because the error can sometimes be a combination of CPU+RAM. It's also good that it doesn't freeze/reboot your system but just crashes the app with the error. I've tried it at very unstable clocks to test.

[G H Z]

GHZ: the error you were getting is typical of RAM instability/fault.

Yeah it's perfect. This system is stock and in some cases I don't even bother testing when there's too many boxes to look at, this one happened to get a little more personal attention

[KiD0M4N]

Yeah it's perfect. This system is stock and in some cases I don't even bother testing when there's too many boxes to look at, this one happened to get a little more personal attention

That error was definitely one off...

I had asked a couple of friends of mine to test it at unstable ocs (where 1M was completing... but P95 worker threads were crashing)... SuperPrime simply rebooted their system.

Since this is managed code, there are 0 memory leaks... so that is out of question. Whats possible is I am, in a certain combination of conditions, released a memory block too early... I will definitely look "DEEP" into this.

@KTE: Yea bro, if it is the CPU, the CLR would crash and would give any sort of exception to me. Let me put some catch conditions around it anyway.

@GHZ: Are you able to repeat the crash everytime? Like... does it crash and then show the result?

[KTE]

Those are just some of my test findings, could be applicable and also unapplicable. If I have an unstable oc on RAM or CPU (pass everything but fail Memtest/P95 in-place large FFT 3 hr), I get no crash on running SuperPrime. It will run on completion and then show up the error towards the final single threaded bench.

I tested RAM CR 1 and 2 like this at DDR2-800, DDR2-900, DDR2-1000 and DDR2-1200. Because 32M would pass with ease but not SuperPrime. If Cinebench 10 (multi) runs fine, then it won't be RAM/CPU fault related.

Was stress testing y'day and this was a saved run.



Full settings were (apart from CR which was 2):

[KiD0M4N]

Hi KTE!

for the thorough testing of the SuperPrime benchmark.

I have a new release for you and it incorporates some suggestions I have received from here and other forums.

Changelog:

Version 0.9.8.3

- Fixed error detection logic to the entire benchmark.
- Renamed the benchmarks to give them more meaning.
- Quadrapuled the memory usage and the intensity of memory checking.
- Fixed certain flaws in the system information detection phase.
- Changed version to 0.9.8.3

Download link: http://forums.erodov.com/local_links.php?catid=7

You should (hopefully....) have been intimated about the same by the earlier versions of SuperPrime as well.

A example run:



Please let me know how this one fares for you

Regards,
Karan

Those are just some of my test findings, could be applicable and also unapplicable. If I have an unstable oc on RAM or CPU (pass everything but fail Memtest/P95 in-place large FFT 3 hr), I get no crash on running SuperPrime. It will run on completion and then show up the error towards the final single threaded bench.

I tested RAM CR 1 and 2 like this at DDR2-800, DDR2-900, DDR2-1000 and DDR2-1200. Because 32M would pass with ease but not SuperPrime. If Cinebench 10 (multi) runs fine, then it won't be RAM/CPU fault related.

Was stress testing y'day and this was a saved run.



Full settings were (apart from CR which was 2):

[G H Z]

@GHZ: Are you able to repeat the crash everytime? Like... does it crash and then show the result?

I tested 9.8.2 again today on the same server and did not see the error again...maybe we can blame MS for this one

9.8.3 looks good, I will run a couple of tests tomorrow

[KTE]

Karan yaar, I've ran the latest version again. Stock.
You can compare to older run here: http://img223.imageshack.us/img223/3...rpmultibz7.png

It's much better now, the CPU usage is excellent and all the config is picked up. But the "checking results" takes a little while longer than the previous version. Still made some excellent improvements very quick!

[KiD0M4N]

I tested 9.8.2 again today on the same server and did not see the error again...maybe we can blame MS for this one

9.8.3 looks good, I will run a couple of tests tomorrow

Thanks G H Z, waiting

Karan yaar, I've ran the latest version again. Stock.
You can compare to older run here: http://img223.imageshack.us/img223/3...rpmultibz7.png

It's much better now, the CPU usage is excellent and all the config is picked up. But the "checking results" takes a little while longer than the previous version. Still made some excellent improvements very quick!

KTE mere bhai, I have more than 4x the memory used during the actual benchmark and during the "Checking Result" stage.

Care to give this a run near 3G? Would love to see how X4 scales the benchmark with increased CPU powah.

Regards,
Karan

[KiD0M4N]

Someone please complete the 256M run on a 64bit machine and post back with the results.... and if possible, a attached .sprime file (right click result > Save.) I need to validate that run... and I cannot run 256M as I don't have a 32bit OS ATM.

[KTE]

I'll try near 2.8GHz when I can. This CPU won't bench something this intensive past those MHz, although I've benched 2.84GHz in 3DMark06. Which shows you how good of a stability tester your app really is.

[KiD0M4N]

I'll try near 2.8GHz when I can. This CPU won't bench something this intensive past those MHz, although I've benched 2.84GHz in 3DMark06. Which shows you how good of a stability tester your app really is.

I think the intensity should have increased somewhat with 9.8.3

Looking forward to some numbers from 2.8Ghz X4.... , and thanks

[KTE]

Hehe, just for you Karan.

Believe me, it is very hard to run these new AMD X4, sometimes even 1MHz above stock does not boot up. Not as easy as X2/C2. So I battled it to bits today. The 2850MHz ran, but it errored towards the end repeatedly. This is what I said about "instability" showing up after you press "Done":


Fastest I ran today successfully was 2816MHz. Some similar runs to show scaling.

[KTE]

There is something wrong with the new build. It runs all test fine until the "checking rsuklts" stage where it takes 4 minutes and then just gives the error above. We are talking stock everything here while the system hardware is completely fine.

[KTE]

Here's adding a 3.6G C2 quad.



You still around karan?

[KiD0M4N]

Here's adding a 3.6G C2 quad.



You still around karan?

Ofcourse I am here :P I am working on the next major build. Yes it slightly slowed down, but a lot of features are being added

[KTE]

Karan, have you made the source code available?

[KiD0M4N]

Karan, have you made the source code available?

Because of the way the validation works, won't it make it a very hackable benchmark (if it takes off i.e.)

[KTE]

You're right in a way there, good thinking.
We have too much of benchmark hacking going on nowadays already and it's next to impossible to catch and ruins all the benchmark.. as well as just hacking in general.

My only point of asking was to look over your CPUZ implementation (to load the appropriate system details), nothing else really. Since you have it working very well.

[KiD0M4N]

You're right in a way there, good thinking.
We have too much of benchmark hacking going on nowadays already and it's next to impossible to catch and ruins all the benchmark.. as well as just hacking in general.

My only point of asking was to look over your CPUZ implementation (to load the appropriate system details), nothing else really. Since you have it working very well.

I can guide you on the CPUz implementation over IM

Also, think your system is stable, give this a run and be ready for some surprises:

Version 0.9.9

- Changed the benchmark subsystem to use Intel LINPACK libraries.
- Added a "stability" checking mode.
- Added a explicit option to run the 64bit version of the benchmark on capable OS.
- Changed version to 0.9.9

http://forums.erodov.com/local_links.php?catid=7

SuperPrime™ - A benchmark to reckon with! - www.erodov.com

Regards,
Karan