The Official Team CUP 2018 DDR3 stage thread:

[Leeghoofd]

Start date will be the 5th of August till the 31st of October.

Verification rules will be expanded versus the regular standard offical HWBot rules:

• CPU-Z tabs for CPU, Mainboard and Memory (+SPD for the memory stage)
• Verification Screenshots are always full screen, no removal of taskbar, no clipping,...
• Retail hardware only (also for motherboards)
• Competition Background must be visible
• To avoid the drama of last year, picture(s) of the RUNNING OC setup has to be added with each submission
• For all 3DMark benchmarks the latest Systeminfo has to be installed (have verification files at hand)
• Only single core GPUs are allowed!!
• If required don't forget to add the verification link!
• List the cpu type/speed/cooling used, motherboard brand/type, Memory/speed and GPU brand/type/clocks in the submission

Competition page here: http://hwbot.org/competition/team_cup_2018_ddr3/

Edited August 4, 2018 by Leeghoofd

[TAGG]

Any limitations on the Xeons for Stage 1 except you can only use one?

Edited August 4, 2018 by TAGG

[Leeghoofd]

only 1 cpu indeed, for the rest no limitations on CPU type, Xeon galore

[Leeghoofd]

It seems the edit function does not work atm, so make sure all the required tabs have the right data and the required pictures are added before submitting!

[Strunkenbold]

Currently the limitation reads like we just allow Xeon UP (single socket CPU) and forbid Xeon DPs (dual socket capable CPU). But from the above, I guess you mean to just allow one physical CPU regardless if it was intended for a dual CPU system. 

Or at least it just confused me... Whatever I changed the server limitation and added another limitation for just using a single CPU.

[bigblock990]

DDR3 stage 6 vantage submitting is broken. Asking for data file, vantage only needs SS and link(for compo) not the datafile itself.

 

[Leeghoofd]

K will have a look, thx for reporting

 

EDIT; should work now without datafile

Edited August 13, 2018 by Leeghoofd

[StingerYar]

Need some clarification about Stage 4 - GPUPI for CPU - 100M FM1

Any version of GPUPi can be used (3.1, 3.2, 3.3, etc), or last ones only? Legacy versions can be used as well (for OpenCL 1.2)?

[yosarianilives]

gonna go out on a limb here and say to follow the rules for bench with the exact same name as specified in comp. Gpupi 3.3 100m is a seperate bench from gpupi 100m. http://hwbot.org/news/11981_application_165_rules/

[Leeghoofd]

12 hours ago, StingerYar said:

Need some clarification about Stage 4 - GPUPI for CPU - 100M FM1

Any version of GPUPi can be used (3.1, 3.2, 3.3, etc), or last ones only? Legacy versions can be used as well (for OpenCL 1.2)?

versions before  3.3 are allowed for TC. Recommended to use 3.2, to avoid any submission issues

Matt is working on a optimized 4.0 version of his benchmark so the 3.3 version will become redundant

Edited August 15, 2018 by Leeghoofd

[StingerYar]

On 8/15/2018 at 10:06 AM, Leeghoofd said:

versions before  3.3 are allowed for TC. Recommended to use 3.2, to avoid any submission issues

Matt is working on a optimized 4.0 version of his benchmark so the 3.3 version will become redundant

It's not possible to use 3.2 on Llano, GPUPi crashes after saving result on windows 7 or instantly closes on windows 10. Used 3.1.1.

[Leeghoofd]

thx for the heads up Stingeryar, I tested 3.1 and yes that one works without any issues, so most will use 3.1 and 3.11

[yosarianilives]

6 hours ago, StingerYar said:

It's not possible to use 3.2 on Llano, GPUPi crashes after saving result on windows 7 or instantly closes on windows 10. Used 3.1.1.

I assume you mean legacy? I've not been able to get normal version of 3.1 or 3.2 to work at all.

[StingerYar]

17 hours ago, yosarianilives said:

I assume you mean legacy? I've not been able to get normal version of 3.1 or 3.2 to work at all.

3.2 usual & legacy versions are not working on any OS, 3.1 usual & legacy are working fine on win10, but not on win7. BTW legacy version is slower

[Leeghoofd]

I got all versions working on Win7 with openCL 1.2, however the effie is nowhere near UnityOC's top score...

[cbjaust]

 yes, but could you save the data file / submit without gpupi crashing?

[unityofsaints]

1 hour ago, cbjaust said:

 yes, but could you save the data file / submit without gpupi crashing?

6 hours ago, Leeghoofd said:

I got all versions working on Win7 with openCL 1.2, however the effie is nowhere near UnityOC's top score...

I really didn't do anything special but one general comment would be that this is an old platform so things like board, BIOS, process priority etc. can make a huge difference.

I streamed my run (it's around the 1 hr 14 mins mark):

... feel free to look for magic tricks in there - spoiler: there are none

I don't have another chip or board right now so there's not much else I can check on my side.

Edited August 30, 2018 by unityofsaints

[Leeghoofd]

7 hours ago, cbjaust said:

 yes, but could you save the data file / submit without gpupi crashing?

Yes no problem... Can't run 3.3 though

[unityofsaints]

7 minutes ago, Leeghoofd said:

Yes no problem... Can't run 3.3 though

Same for me. v3.2 regular ran fine, v3.3 only legacy worked.

[mickulty]

Replicated the efficiency, this is a full stock 3870K with minimal OS tuning kicking the crap out of every other 3870K score on the board

GPUPI_for CPU_100M_01m-18.433s-NOSS.result

System is using an A75-UD4H, 4x1GB SS D9JN sticks, Intel X25-M SSD and HD 6450.

Steps taken to reproduce:

• Place motherboard on OBT
• Install CPU, RAM and GPU
• Connect all cables and peripherals
• Install Windows 7 SP1 (in my case from a disc image that includes .net 4.5)
• Set visual elements to max performance, power plan to max performance, disable UAC (this really shouldn't matter much...)
• Install HD 6450 series GPU drivers (15.7.1 WHQL)
• Download GPUPI 3.2 (NOT legacy version) from https://www.overclockers.at/news/gpupi-international-support-thread
• Run benchmark

There are slower scores out there with a UD4H so I seriously doubt it's related to the board but I have an asrock A55 board I can try if people want, more likely it's the openCL version though.  This is my first time running GPUPI on this platform and I didn't do anything I wouldn't have done anyway so from this first test I'm not sure how other people are so slow.

EDIT: For my own satisfaction I threw the asrock board on the bench with the X4 631 and random ram it happened to have in it, hooked up the same OS and... 2m42s.  Probably shouldn't have opened that can of worms at nearly 1am, I'll have to look into it tomorrow.

EDIT2: Speedup is on bios versions F2-F4 on the A75-UD4H.  F5, which updates AGESA to 1.1.0.3, loses the speedup (1m20s to 2m16s full stock 3870K).  I'm not sure what the mechanism behind it is but it's not timer, and I'd hope the work is getting done because if it's not then GPUPI 3.2 is badly broken.

EDIT3: Similar speedups happen on GPUPI 3.0.1 and 3.3.2 legacy.  Screenshots in an imgur album because this post is long enough already: https://imgur.com/a/lUQee6G (by the by, what's with the hwinfo regression?)

Edited September 1, 2018 by mickulty
new information

[_mat_]

Nice research, thanks for that!

First and foremost: It's impossible to get the right result with GPUPI without "getting the work done". GPUPI calculates the result digits of pi by accumulating millions or billions of intermediate results. The final sum of all these calculations are the digits of pi which are written next to the result time. There is no way to break this if you don't fuck the benchmark (= knowingly cheat by changing memory or executable code).

What is always possible (also unknowingly or unwillingly) is to run into unreliable time measurement of the result. Are you sure that these results correlate 100% with the real time the benchmark actually ran. It should be easy to see when one second is displayed as two in the benchmark. And when GPUPI is using RTC the same time skewing should happen with the OS clock in the task bar which uses the same hardware and software functionality to measure time.

If the slower runs are really timed correctly then there is only one explanation: It's actually faster.

[unityofsaints]

48 minutes ago, _mat_ said:

Are you sure that these results correlate 100% with the real time the benchmark actually ran.

Dude it's in the video. Unless I found a way to slow down the way I talk and act in real time, this run really took 53 seconds It the actual speed of the processor which is affected. This is not a bug in the bench, clearly. It's simply a case of the later AGESA running OpenCL workloads much slower.

[_mat_]

I saw your stream multiple times and measured your final run too. I know it's realtime. But I was actually talking about the slower runs that mickulty has on other mainboards.

[Leeghoofd]

Are you using the SDK 2.9.1 too Mickulty or the one from the VGA, which version is that?

Johannes did some testing too and said it is 99.9% related to the AGESA code of the initial GB bios, I tried his OS, SDK drivers and can't replicate it on it the Asus nor the cheap ass MSI  board... 

Looking at both your testing it seems to be related to the bios, which has a play with the GPUPI benchmark... sadly if this is the case I can not approve the scores as the efficiency is way off versus other available hardware.

[unityofsaints]

4 hours ago, Leeghoofd said:

Are you using the SDK 2.9.1 too Mickulty or the one from the VGA, which version is that?

Johannes did some testing too and said it is 99.9% related to the AGESA code of the initial GB bios, I tried his OS, SDK drivers and can't replicate it on it the Asus nor the cheap ass MSI  board... 

Looking at both your testing it seems to be related to the bios, which has a play with the GPUPI benchmark... sadly if this is the case I can not approve the scores as the efficiency is way off versus other available hardware.

Did you flash an older BIOS on the Asus bord Leeg? 1102 for example would be old enough.

Edited September 3, 2018 by unityofsaints