_mat_

Processor doesn't support AES-NI instruction set, so BenchMate can't verify that the files haven't been tampered with. I have already wrote a backwards-compatible code path that no longer imposes that limit. It will be released with BenchMate 0.11.

I do think it is just the mixing of BM versions and that your problems will be gone with BenchMate 0.11. If that's not the case, I will need a proper bug report (or zipped log files), so I can thoroughly examine what's wrong.

BenchMate already has it if you submit online from within the client. If you bench offline, just copy the result folder to another BM install on your normal PC (json and hwbot files at least). Select all results in the result list and submit. Or use BenchMate on a USB stick and just plug it into your PC after the session.

It is not just a single executable, it is so much more. It is a launcher application, three services, a kernel driver, the client application and 5 DLLs. Then there is the bug report tool and a hardware detection debug tool. I made it portable, because I knew that this will be the best for overclockers. You can even run it on a USB stick, it works just as fine. But if for example the system hangs and leaves broken services behind, these will interfere when you start a different BenchMate versions afterwards. In any case, this has been fixed and will be soon available for download. I'm really close with finishing BenchMate 0.11, which will make our lifes better for sure. Don't forget that this is an alpha software from a single guy that is so low on funding, that it's not funny anymore. This is early stages for something that nobody has every tried before. It is supposed to be no fun.

Unbelievably good!

I was the first to break 3G on AMD and started the whole Bulldozer memory frequency crap by taking the DDR3 crown with 3311 MHz. That was a wild time for memory overclocking for sure, lots of hours and money spent to be on the top. And all that's left are 1.5 hardware points. I personally couldn't give more of a fuck, I'd rather see these achievements displayed/promoted in a better way. Being listed in the record list a lot more satisfying than hardware points: https://hwbot.org/benchmark/memory_frequency/ So that's why I think that a better timeline for records, separated for example by platform could be a way out to have more flexibility for decisions regarding benchmarks and its points. Additionally a list of lifetime achievements on the user page would be nice. Something like: * First to achieve 100.000 points in 3DMark01 * Held the Super Pi global record for 35 days in Nov 2015 Benchmarks and points come and go, achievements are here to stay.

It amazes me that everybody thinks XOC is dying while demanding that nothing should be done about it at the same time. That's not how it works. HWBOT needs to adapt to the new challenges today, not dwell on the past. We have a saying in Austria: "Was sich nicht bewegt, ist tot", roughly translated into "If it's not moving, it's dead". Moving on does not devalue the achievements of the past. Those were celebrated until the next record comes along. That's XOC. The only thing that sucks is that these achievements are not properly frozen in time. So let's ask the question how we can honor benchmark results from the past. Two things come to mind: Implement a nice(r) timeline to revisit the records of each generation. Freeze the ranking or at least seperate it from new results after the benchmark was frozen. Seeing records made with zombie-modded beauties on liquid nitrogen getting replaced by a workstation card two years later isn't fun to watch. For what? A few hardware points? Maybe we should have a look into properly preserving our achievements other than trying to hold on to them as long as possible. Fun question to prove my point: Who was to the first guy to break the DDR3 3000 barrier?

I am not allowed to do anything with Geekbench. The dev threatens with a lawsuit because I'm obviously profiting from derivative work by fixing his product with a free tool. ?

That only shows that we desperately need a real memory bench to legitimize good memory kits. My concern about Geekbench and other benchmarks that deliberately don't give a rat's ass about competitive benchmark is, that sooner or later it all comes back to HWBOT for not being "fun". We already have no control over the development of Windows, CPUs, hardware timers and much more, and look where that got us: Is this what fun looks to you? It is definitely not for a newcomer or somebody that just wants to show off his system. That's why Geekbench is still so popular. You need no effort to make it work, it just does. But popularity doesn't say anything about the quality of the score. That fat "N" in the list above and my research tells a different story. They are going for quantity and their results are not appropriate for competitive benchmarking or in fact worthy of any kind of ranking/list. So the last thing we need is that benchmark developers walk all over us as well. It is an absolute necessity that we cooperate with these devs to work around the issues we certainly have no control over. If the developer doesn't want that, we have a single weapon to decide our own future: global points. So please let us them wisely.

BenchMate is implemented to use next to no ressources, especially during the benchmark BenchMate does nothing to interfere. All action is triggered by hooks inside the benchmark process, which dictates what BenchMate is showing. The only exception is the sensor measurement, that happens once every second. We need that to define the new benchmark standard that gives more understanding what happens during the benchmark. This will make much more sense with BenchMate 0.12, were all the data will come to life. It's going to be a beatiful graph orgy for sure. What happened exactly? BenchMate applies next to no load on the CPU when it is starting up. The only part that does need some ressources is the verification of the installation files to make sure they weren't tampered with. I doubt that this comes anywhere close to the workloads that Geekbench applies.

The red X is due to the many threads using a lot of timer calls during Geekbench, which had the possibility to colide inside BM's kernel driver and produce a skew error, which will ultimately get blocked. This has been already fixed of course, but not in BenchMate 0.9.3. This is exactly what happens when I'm not allowed to support Geekbench with the latest BenchMate versions. People go back using old versions with bugs that have already been fixed, mixing up BenchMate versions that leave artifacts due to crashing and inevitably fuck the installation up (unless you know what you are doing and remove the BenchMate services manually). Worst case scenarios that all fall back to BenchMate, exactly as I predicted. Geekbench needs to either allow the integration or lose its points. This is not fun for anyone of us.

Did you use multiple BenchMate versions on the same OS? Switching between 0.9.3 and 0.10.x for example does this. The upcoming release allows new versions to be run right next to old ones without any conflicts. Services, driver and all are available seperately for reach version, each component has their own version postfix. So please be patient, the next version will improve on all fronts.

You are doing nothing wrong, mate. BenchMate only validates benchmark results, not frequencies. I'd like to leave that responsibility with CPU-Z for now. Just submit the validation link with your score manually. No screenshot needed according to the rules: https://hwbot.org/article/application_13_rules If you have any questions regarding BenchMate, hit me up in the BenchMate support thread:

You need to use BenchMate to save your result file, don't do it within GPUPI. The hardware detection and submission upload in GPUPI hasn't aged well and is unstable. For the next BM version I already added a warning and disabled this functionality, so people can't use GPUPI result file saving.

NVIDIA driver accessing the process memory of the benchmark, which is for obvious reasons not allowed. I have already fixed this, it will be released with BM 0.11. You can either use BM 0.9.3 (which does not protect against that specific memory access) or an AMD graphics card.

First successful results of BenchMate 0.11 running a QX9650 on an ASUS MAXIMUS FORMULA and a GTX 9800. ? 3DMark03: https://hwbot.org/submission/4328329_ SuperPI 1M with Virtual RAMDisk enabled: https://hwbot.org/submission/4328289_ CPU is at 3G, don't hate me. It was hard enough to get the system working, making BenchMate compatible was rather easy in comparison.

You are probably using a CPU that is currently not supported. The AES-NI instruction set is necessary for now to do fast file integrity checks. The next version, BenchMate 0.11, won't need the instruction set and runs even on socket 775. That's the oldest platform I have here for testing. It will be available for download in the next couple of days (asap).

@KaRtA You used BenchMate for your sub 6 run, I guess to make use of the Virtual RAMDisk tweak, right? Why didn't you do the screenshot with the result dialog as well? Would have been much more trustworthy to know that SuperPi wasn't tampered with and that timers were not skewed.

You should get these three files after you took the result screenshot via the "Save Result" button. The .hwbot can only be uploaded to the "wPrime ... with BenchMate" categories for now.

7G on 8C/16T + 5G CL14? Fking crazy if you ask me. :D

Thank you, @keeph8n! @lunatic@98, my request for a bug report was meant for you (as well). It would help a lot to fix this.

The result was made using a graphics card that can't be correctly matched or the integrated HWiNFO library can't read the GPU's sensors correctly. That's why the GPU and GPU memory frequency rows are marked as red (invalid). Please submit a bug report from within BenchMate (in the menu of the main dialog) after you have finished a 3DMark run that would lead to an error like this. Thank you in advance!

Thanks for your kind words. I will integrate y-cruncher and x265 with the next release. Both are a little bit harder to integrate because their wrappers are built with Java, which is impossible to secure. So another solution has to be found, I'm not sure yet how this will turn out, but I'll find something. As for the SuperPi bug. I have encountered this but could never reproduce it two times in a row. Thanks for the bug report, I will look into it!

Yes, you can move your old results into the new BenchMate installation. You can always move/copy the following files to a new BenchMate installation directory. Close BenchMate first, then move/copy, start BenchMate again and all your benchmarks and results should up after restarting BenchMate. Old-BenchMate\results\* => New-BenchMate\results\ Old-BenchMate\config.json => New-BenchMate\

It's not a bug, security always has its performance penalty. Although there is next to no impact on most benchmarks, wPrime is different here. That's why I initially refused to add it, but got convinced by the popular vote. wPrime is coded in Visual Basic 6, a programming language not suited for multi-threaded applications. To achieve threading it uses a COM object server, which actually starts two wPrime processes per thread to calculate and communicate the progress and result. The startup of these processes is part of the time measurement as well, so when you run wPrime you are also benching the COM object client spawning in addition to the normal workload. To secure all these processes, BenchMate has to add a security layer to each process. This is normally done only once when the benchmark application is started. On wPrime with Threadripper this has to be done dozens of time. I optimized the hell out of this, but I can do only so much. In any case, you can't bench wPrime with AMD on Windows 10, so you should compare it against a Windows 7 score. According to the scoreboard it seems like Windows 10 + BenchMate is still winning.