MaxxMem, The Truth

[Christian Ney]

Tell me which one are bugged

You can choose multiple answers for the poll
RUN1


RUN2


RUN3


RUN4


RUN5


RUN6


RUN7




SF3D and Chew* are more active on XS I think. Wish they will see that, as I am always on hwbot and not on XS yet.

[Christian Ney]

Poll added

btw you can choose multiple answers for the poll

[Mr.Scott]

Not enough info to make an accurate assessment. Were they all run on a fresh boot?, and what processes were running in the background of each?

[knopflerbruce]

Maybe he's trying to say that it's impossible to figure out what runs are bugged or not

[Mr.Scott]

That may be true, but without all the pertinent info you'd never figure it out anyway.

[Christian Ney]

Originally Posted by Mr.Scott

Not enough info to make an accurate assessment. Were they all run on a fresh boot?, and what processes were running in the background of each?

Always fresh boot between all runs
No processes runned in the background or while MaxxMem was running
There is all info that you need to provide for the top 20 "Hall of Fame" in the SS I made

Originally Posted by knopflerbruce

Maybe he's trying to say that it's impossible to figure out what runs are bugged or not

Some guys are 100 % about a bugged or not MaxxMem's run

[chew*]

Well first off not all of your runs are on equal terms.......so that tosses consistency out of the equasion.

You changed stuff between boots.

Dual channel, single channel or were so unstable you were dropping channels for starters.

Not sure what point your trying to prove but your going about it wrong.

All things equal between boots = 2 drastically diff scores = some form of bug or inconsistency.....however in my experience if you can boot chances are you will not bug.....

The problem with bugged runs is people boot lower becasue they are not stable enough to boot higher, then they clock up in windows.......thats when the bugging shows up.

Could be something as simple as the system clock going out of whack whilst running the bench due to instability.

For me it was a simple case of hey the freaking asus board is limited to subs that can be used.

Crucial timings are limited to 4-4-4 and I think 8 as lowest. I knew exactly what the max possible was, I used both boards, I knew which boards could do what.
The giga could pull all those timings to 1-1-1-1 and for my runs they were certainly tighter than 4-4-4-8.

Timing limitations that don't exist on the gigabyte. Combine that with another bench ( 32m pi from all parties involved ) also very sens to timings......and things just did not add up

Of course I recently had that remedied for the M4E but prior to 1298 it just wasn't possible.

Last but not least having not ever used that platform I could not make an accurate analysis.

I only make analysis of scores after i have run the same platform at the same speed on the same board or equivalent ( many hours/days on end ). Just like you should be analyzing the same way before trying to "prove disprove" something.

[dinos22]

Look at your latency scores and go from there i think

[SF3D]

I thin chew have some points here.

You need to have same platform and huge amount of testing. Then you learn what is bugged run and what is not with that certain platform. It is almost impossible to start shouting which one is bugged and which one is not, if there is no 50h+ testing behind.

I am sorry to say, but this thread is pointless. You can not prove anything with this sort of poll

[Christian Ney]

Then, I have to run it 1000 times and add 1000 Screenshots to the Thread ?

Why keeping so bugged benchmark if you all know it's easy to make it bug ?

To all, runs are made with the settings provided on the screenshots, I haven't changed the FSB, memory timings or tweaks within Windows 7.

And the system is 100 % stable, I can run any benchmark without bug, memtest, OCCT....