UCBench11: Tweaks and Luck

[Splave]

Yeah I know he's on XP, but does it really make that much of a difference? I'll definitely try then

 

ok ok ok

 

XP64

-Set Background Process Priority

 

and dont thank me anyone

[HiVizMan]

ok ok ok

 

XP64

-Set Background Process Priority

 

and dont thank me anyone

 

er, thanks

[George_o/c]

ok ok ok

 

XP64

-Set Background Process Priority

 

and dont thank me anyone

 

Thanks man

 

However I still think that rules have to be clarified first, and I'm glad that as seen in your other thread, hwbot staff is on it. I'll wait for a bit

[GENiEBEN]

If you're reading this post than you probably had a blocked UCBench score. What we once considered "luck" turned out to be a design flaw of the benchmark, documented by a fellow member of the HWBOT community (credits pending) and personally tested for veracity.

 

TL;DR: The Passwords Checked column must be in ascending order (A<B<C etc)

 

How to make sure you're not going to get a bugged score:

Make sure that thread selected divided to total available threads (cpu threads) is not an odd number.

Let's take an example: -cpus=24,53,60 ; with a physical CPU that has 4 threads (4c/4t, 2c/4t).

Benchmark only cares about every other second thread (24,53,60 -- A,B,C,D,E,). This example will be bugged since 53 divided by 4 will result into an odd number (13) AND is also second in line. If we were to rearrange our original choice, we could return a valid result using: 24,60,53. Notice that since second number divided by 4 is now an even number, the result won't be affected.

 

We will refer to this rule as "A<B<C", in case you're wondering what mambo-jumbo were talking. Speaking of which, scores that resemble "A>B~C" are technically bugged but they will be at moderator's choice, with the chance of staying in the rankings.

===================================================

UPDATE 16 May 2014: TL;DR

UPDATE 22 June 2014: Typo in A<B<C

Edited June 22, 2014 by GENiEBEN

[Strunkenbold]

Whats the exact case for single cores? There are obviously bugged scores as well using just 1 and 64 threads. And 64 would be even. Or are these results ok?

[Moose83]

This example make no sence! Just make wrapper, or disallow this threat stuff completly You also get bugged runs with even numbers

[mr.paco]

So I could maybe get a better understanding of that explanation, could you let me know if this run is good or bad.

And if it is bad; Why?

 

 

Thank you for your time...

[Crabby]

That is bad mr.paco and here is why: 2/2=1 and 6/2=3.

[mr.paco]

That is bad mr.paco and here is why: 2/2=1 and 6/2=3.

I have no idea what that means

I am in no way trying to be a pain, but could you possibly explain that in layman's terms please ?

Appreciate it..

[Crabby]

#threads 1,2,3,4,5,6,7,8 and 64. Every other number counts, so in this case its 2,4,6 and 8. These are the ones you divide by the amount of cpu threads you ran with. 2 divided by 2 is 1. One is an even number and so a bugged run.

[Mr.Scott]

#threads 1,2,3,4,5,6,7,8 and 64. Every other number counts, so in this case its 2,4,6 and 8. These are the ones you divide by the amount of cpu threads you ran with. 2 divided by 2 is 1. One is an even number and so a bugged run.

 

One is odd.

I knew what you meant though.

[mr.paco]

Thank you Crabby.

I appreciate the explanation.

[ObscureParadox]

Let's take an example: -cpus=24,52,60 ; with a physical CPU that has 4 threads (4c/4t, 2c/4t).

Benchmark only cares about every other second thread (24,52,60 -- A,B,C,D,E,). This example will be bugged since 52 divided by 4 will result into an odd number (13) AND is also second in line. If we were to rearrange our original choice, we could return a valid result using: 24,60,52. Notice that since second number divided by 4 is now an even number, the result won't be affected.

 

Unless I'm being dumb, your example would also be invalid because 60/4 = 15 i.e. an odd number

 

What's the deal with numbers that don't divide exactly into each other then, I assume they are also invalid?

Edited May 4, 2014 by ObscureParadox

[Mr.Scott]

So....in theory then, a totally default run on a X3 Heka for example will always be a bugged run?

 

Bullsh1t. I don't buy it.

[GENiEBEN]

So I could maybe get a better understanding of that explanation, could you let me know if this run is good or bad.

And if it is bad; Why?

 

Thank you for your time...

 

What Crabby said.

 

Unless I'm being dumb, your example would also be invalid because 60/4 = 15 i.e. an odd number

 

What's the deal with numbers that don't divide exactly into each other then, I assume they are also invalid?

 

Thanks for pointing it out, you are correct, those numbers were for the dual-core cpus, should have picked new ones for 4c/4t.

 

So....in theory then, a totally default run on a X3 Heka for example will always be a bugged run?

 

Bullsh1t. I don't buy it.

 

The cpu can actually complete those even threads without carrying over to next thread selection.

 

X3 with 3,15,60 = good

X3 with 4,16,64 = bad

X6 with 6,24,60 = good

[riska]

I cant see the problem here? why not just use the stock settings for the bench, and disallowe the user to set the threads them self?

[Doug2507]

Because it removes part of the fun, we all like benches that you can tweak! Although having said that maybe it's not such a bad idea if system settings still have a big influence, that would still leave room for manoeuvre.

 

I guess another option would be just to shit can it and enable points on another bench. Would also save having to sort out 12k worth of subs!

[Moose83]

I cant see the problem here? why not just use the stock settings for the bench, and disallowe the user to set the threads them self?

 

 

 

Im also for disallow all threat settings...Then there is no problem like we have now

The bench is enough tweakable only with tweaking the OS

No one wants to bench with math calculator lol

[ObscureParadox]

X3 with 3,15,60 = good

X3 with 4,16,64 = bad

X6 with 6,24,60 = good

 

Now I'm confused again because 15/3 = 5. Am I right in thinking then that with an odd number of cores we need the division to equate to an odd number too or does it also have to be even and this is another mistake in the example??

[GENiEBEN]

Am I right in thinking then that with an odd number of cores we need the division to equate to an odd number too[...]

 

You are correct.

[Strunkenbold]

Actually 12k results are way too much to get moderated by 2-3 persons. This will take ages. We probably should consider making a clean cut here. There are more up2date benchmarks out there dunno what is so special about UCbench that we have to keep it.

[Moose83]

Just disallow this threat settings and done Its more math then benching with this threat count...

[ObscureParadox]

You are correct.

 

woot woot!!! I'm getting somewhere

[Mr.Scott]

 

The cpu can actually complete those even threads without carrying over to next thread selection.

 

X3 with 3,15,60 = good

X3 with 4,16,64 = bad

X6 with 6,24,60 = good

 

 

You missed the point. Default settings for the bench automatically selects 1, 2, 3, 4, 8. A 3X core running 3 threads should be bugged according to your math.

[GENiEBEN]

You missed the point. Default settings for the bench automatically selects 1, 2, 3, 4, 8. A 3X core running 3 threads should be bugged according to your math.

 

Except it never is bugged on default settings, I know what you meant.

Will update my post tonight with the answers I gave through PM's.