_mat_

What are the problems you are refering to? Without a detailed description it's difficult to help. As for step by step for Intel CPUs: Download the latest Intel OpenCL runtime: https://registrationcenter.intel.com/en/forms/?productid=3207 Open GPUPI, "Calculate", select your CPU in the latest Intel OpenCL platform you can find in the settings dialog and run. There could be inconveniences regarding your OS timer, where GPUPI states that you can't submit due to possible timer skews. Either enable HPET (GPUPI 3.3 will give you that opportunity by just pressing a button) or run Windows 7 or Windows 10 prior to RS5.

Thanks for the report, will have a look at it as soon as I can. Hope I still have X79.

I've looked into R20. Timers have not changed much, it still relies mostly on timeGetTime (uses RTC) and additionally QueryPerformanceCounter (mostly TSC or HPET if manually enabled in OS). I still think that timeGetTime is the primary timer to measure performance as QPC is mostly used for UI dependend stuff internally in Windows while timeGetTime is only used if the developer chooses to do so. Anyways R20 should have the same OS/platform restrictions as R11.5 and R15. Btw timer calls can be easily shown with my TimerBench project (menu Tools => Measure). An advantage of R20 is the missing scriptability. While R15 is scriptable via Coffee script, R20 seems to have no such functionality. Coffee script support is huge vulnerability currently present in R15, an easy one-liner can simply set a new benchmark score. Problematic are the configuration options available to customize the benchmark run in R20. There are a number of options listed in resource/config.txt which can also be applied as a command line argument. I have not figured out yet if changing these values will impact the benchmark score. But it was possible for example to run the test with 128 threads instead of the normally chosen 16 for my 9900K (-200 points) and enable a console: So that should be looked at, but as far as I can see it, R20 might be the better choice in terms of security.

I only meant the web submission of course. If there is an error while saving the dat file, it's a benchmark issue. marco, thanks for submitting the ticket. Didn't get around to it.

I have the same problem on my dev system as well. It's because the online submisson returns an HTTP error 400 when submitting. It's the same issue as:

The HWBOT data file upload often gives very cryptic error messages when uploading into a wrong category. I am getting similar requests from fellow overclockers all the time, so this is definitely something that needs improvement.

Great work! Bulldozer is as fun as overclocking can get.

Crazy! ❤️

I don't know when it stopped working, but I am getting reports since January that GPUPI crashes when submitting online while data files are working. As websmile was able to submit a result with y-cruncher half an hour ago, I guess the problems are related to a specific combination of OS/hardware. I am currently working with Win10 RS5 + 9900K/Z390 and 2990WX/X399. Both platforms have the same submission problems. Do you have a detailed error log for these HTTP 400 errors? The response body is an HTML error page btw but no specific information on it. I am guessing it is triggered by the web application.

Pushing this. Online submission is not working, guys! @richba5tard

The submission API currently returns a 400 error. No specific error message. Doesn't work with GPUPI, y-cruncher and x265. @richba5tard @Leeghoofd

Wild mix!

To anyone wondering why GPUPI is currently crashing with the W-3175X: I am working with Intel to fix the problem. No CPU sample of course, but they get me in touch with the benchmark guys. I sincerely hope that they deliver so GPUPI can help to prove the true value of this overpriced chip. ?

@tiborrr (benched like crazy back in the day! also left EKWB) @Monstru (still kicking hardware at lab501 though, but won't sub on the bot anymore)

XTU doesn't need AVX, there are code paths inside the inner benchmark executable without AVX as well. You can also disable the AVX path via a configuration file, details in my article here.

Seems like the category has to be added manually by the mods to make it work. @Leeghoofd?

OpenCL support for CPUs will be deprecated in GPUPI 4 anyway, so this won't be a problem in the long run.

Well, I'm not a lawyer. My personal opinion is to not give a fuck about any of that.

AMD has no official links for its APP SDK, that's true. I will upload them to overclockers.at for better availability. As for Intel OpenCL runtime I have no clue what you are talking about. You are from Germany, right? Here is the latest Intel OpenCL runtime: https://registrationcenter.intel.com/en/forms/?productid=3207

Looks good, I like the new responsive design. Some tables (ranking for example) still need some work by either removing unnecessary columns and/or pinning the first column and add the scrollbar to the other columns. Like this: https://zurb.com/playground/projects/responsive-tables/index.html

I already have a Prime95 benchmark ready that scales pretty much perfectly and is very hungry for memory bandwidth. It is using the latest Prime95 version (29.4) and includes a few fixes like NUMA awareness, improved thread synronization and error checking. It's also faster than the XTU version. It seamlessly integrates into XTU so you can start XTU with an AMD CPU and just run the benchmark. It won't be far off to create a WIN32 application that runs the bench and uploads the score to HWBOT. Is this something the community would be interested in?

Yes, every benchmark is breakable and nothing is 100% bulletproof. But that's not necessary, we only need to increase the cost for cheating to a level where it's easier/cheaper to just overclock and make the damn score. Overclocking has no 100,000 USD competitions, so it's not an impossible task. Regarding your benchmark and its current state of security: It took ~2 hours to break HWBOT Prime 1.0 and your bench and I've never written a single Java desktop application. it. No debugging or code changing involved, only static analysis of your executable. If you need details on how to reproduce this, just let me know and we'll chat.

Now that XTU will have its global points removed soon, I am officially publishing my findings on this benchmark. I tried to give full insight on how to disect and uncover the security issues of XTU but also some tweaks and the possiblity to run the inner benchmark executable on its own for quick performance testing and points calculation. https://www.overclockers.at/articles/intels-xtu-analyzed This is not some kind of personal vendetta against Intel; far from it. The article's purpose is purely educational to raise awareness for benchmark security and timer reliability. This is not only about cheating, it's about the credibility of benchmarks and result databases like the bot as well. Security vulnerabilities are not taken seriously enough by benchmark developers and HWBOT in my opinion. Yes, I am going the hard way with XTU in my article of course and that's not for everyone. But there are already tools available for download that will get you ahead without any effort. So I'd like to start a discussion here on how we can improve the situation permanently. It goes without saying that any serious initiative would require a cooperation from all sides involved.

Yes, it's ok.

Congrats Allen! So much research and effort behind this awesome score!