_mat_

The BenchMate categories only exist for automatic uploading from within BenchMate. It's a technical issue, because some of the old categories (Super PI, wPrime, ...) do not support the HWBOT submission API. So yes, you can just take the screenshot and upload it to other (matching) categories. See BenchMate as additional proof for a valid score.

Something we should think about is the definition of "maximum frequency". Right now with CPU-Z the definition is that the CPU's sensors can be read and the CPU can produce an encrypted result file (which implies disk I/O, multiple levels of drivers invoked, CPU-Z version-dependent code, ...). It's also not a very stable definition as it can change (and has changed) between different versions of CPU-Z. The right term instead of "max frequency" would actually be "CPU-Z validation stable". So before it makes sense to code anything, we should try to define what "max frequency" really should mean for us and also for the outside world. And how this value is communicated to be credible. How it's technically done is for now irrelevant. The requirements will define that.

Of course. It would need to be done using BenchMate anyway because as soon as we are talking validation, security and timers, you will always end up with the same conclusion: it all sucks and needs a whole concept to make sure that it is foolproof, hard to cheat and easy to use. New BM version will also let you close the client at any point. So only a background service is running to measure sensors and the driver enables correct time measurement and that's it. That said the saving of validation files should be done differently as well. Also without the client and with a single hotkey. So new BM versions first, new suicide runs later.

Maybe this is the right time to discuss that the validation of a fictional number like the CPU frequency is not a credible basis for competitive ranking. I'm thinking a small workload would be more suitable for this kind of task (idea by @mllrkllr88). Something completely independent of memory, but big enough to show the scaling (in comparison to other CPUs of this generation). This workload could even come in multiple flavors like single-threaded, multi-threaded, AVX*, each separated into their own categories here on HWBOT. Not an easy task all in all but a big improvement for the moderation and therefor the credibility of suicide runs. Edit: It also makes a lot of sense to use effective clocks instead of the fictional numbers. Much more reliable (although harder to comprehend for the overclocker when benching).

I think I found the culprit: It's a bug in the 32 bit version of BenchMate's driver. The 32 bit version will be removed starting with BenchMate 0.11. It's just too much effort to test all the different combinations of OS versions and 32/64 bit and I don't have the necessary resources.

Hmm, just rechecked. I don't think that 7-Zip even uses a decimal point here. The score is just completely bugged. @Sir_Nobs_of_rone_II. Did this happen once? Or reproducible (each time)? Also can you try without BenchMate? Just use the parameters from the command line in the bench dialog. You find the 7-Zip bench in the apps folder of your BM install.

Seems like the output uses a wrong locale without a decimal point. Probably a bug in 7-Zip itself. Maybe I can force the locale from within BenchMate. Will have a look at it. Score needs to be deleted.

6900 XT and probably 6800 as well are currently not compatible with GPUPI. It just doesn't compute right for whatever reason. Edit: You error above nearly always means that you need to reduce the Reduction Size step by step. AMD GPUs have very limited space for shared memory.

No, it doesn't allow online validation links with (detected) timer issues as far as I know. But there are multiple ways to get a skewed offline score in the latest versions. I detected one recently on Zen 3 with specific motherboards without even touching the reference clock (which is normally detected without problems). So online validation for latest UL products is necessary for reliability in my opinion.

The TSC detection is probably not working in the submitter. Empty cells in the clock column are very likely TSC. y-cruncher scores are invalid when running on AMD and Intel pre Skylake with TSC on Windows 8/10. The examples above are on Skylake X, so they are fine timer-wise.

Great, please lay it to rest. If anyone wants the encryption keys of the bench to roll your own results with a single command line call, just let me know.

Yes, the remote access is theoretically a problem. Please try with local access. Your bug report for wPrime states that I can't capture anything from wPrime's result window. So it can't verify the category that was running, hence the error in parsing the result. PS: wPrime is pretty difficult to integrate. I already wasted a lot of time with this bench. Support will slowly fade out from my side. It's just not worth the effort.

@cbjaust As I can't send any PMs today anymore (I've reached the daily limit of 5) and this may be of interested to others anyways: The support of 3DMark03/05/06 is currently very experimental. We have a way better implementation ready in our dev builds, that will correctly detect iGPU, SLI and Crossfire. It also measures only the sensors of the cards involved. In fact the whole 3D integration was completely rewritten, even that of GPUPI when used with graphics cards. This will come out with one of the next releases soon. In the long run 3D will get a way better treatment. I'm talking about game benchmarks. So please sit tight and yes, your bug reports about GPU clocks were looked at when they were reported and are flagged as "TODO" in our bug report database.

This OS version is untested. Some people are using the Standard Server version though and it seems to work. Don't know if anyone has tried 2019. As for wPrime, can you submit a bug report after the error occurs? Best to close wPrime first and go to the client and select bug report from the menu. GPUPI, the error states that BenchMate can't inject into the GPUPI executable. Might be an incompatibility or some kind of protection from the OS or an Antivirus software. If you have AV installed (even Windows Defender), try to deactivate it temporarily.

GPUPI 3.3 was never meant to be in its own category. It doesn't know about the change in category. That was decided afterwards from the bot. I remember the time well, I nearly turned my back on HWBOT and needed to take a few months off. The fork was wrong, but releasing an optimized version of the bench and not bumping the major version to 4 was wrong as well. Leeghoofd and I agreed to get rid of the situation as quickly as possible. I will finish GPUPI 4 after the upcoming BenchMate release and I'm gunning for end of February.

Thanks, will have a look at it.

BenchMate 0.10.7 is now available: https://www.facebook.com/benchmate.org/posts/237361107992580 This bug is fixed in the new version.

Not necessary with BenchMate checking the file integrity of CINEBENCH. This is also stated in the rules. I do advise though to use the "Save Result" to save your screenshots and upload the submission file to HWBOT as well. I know it's not in the right category, but otherwise we are still dealing with pixel data as proof.

There is a bug right now with Skylake X (missed one workload executable to secure, my bad). The latest prerelease of BenchMate fixes it (0.10.7). Only available for Patreon supporters for now: https://www.patreon.com/posts/50-patrons-and-0-46675312 @Leeghoofd I will send you the details for PYPrime so we can make 0.10.7 available for the public asap.

F-Secure is known to not work. Windows Defender is for example working out of the box. Yes, of course they are working without BenchMate. The benchmarks don't recognize if their memory is changed. That's one of the reasons why BenchMate exists. You can try to add an exception to F-Secure so it doesn't scan benchmark processes from the BenchMate installation directory.

What AV are you using?

Do you have an Antivirus tool, anti cheat tool or any other intrusive software installed? The error message states that something wants to write into the process memory, which is not allowed as you could easily change the score or the workload by doing so.

The resulting hash is invalid. Not by much, the last hexadecimal digit should be 8, but it is 9. This looks like a rounding error. It's probably an OpenCL driver bug triggered by a kernel/compilation option in GPUPI 3.3. You can try different/older drivers, but I can't promise you anything. That's exactly what happens if you don't get the graphics card to test and fix a benchmark. They will stop working at some point when the vendor changes pile up. 6900 XT doesn't work as well.

System might be unstable. But according to the FAQ it can be many things. "My computer is completely stable. But I keep getting errors such as, "Redundancy Check Failed: Coefficient is too large." The notorious "Coefficient is too large" error is a common error that can be caused by many things. A full technical explanation is here. Because of the nature of error, it can be caused by literally anything. But below are the two most common causes" http://www.numberworld.org/y-cruncher/faq.html

I looked into swap and would have liked to integrate it, but if I remember correctly it is not (completely?) configurable over command line. An additional config file seems to be necessary to set up the swap disk in detail. I might add this possibility later on if it can be ensured that the configuration file does not override the command line parameters. @Mysticial Please correct me if I'm wrong.