The official BenchMate support thread

[Guest 0.0]

Just a reminder that the CBR "keep best score" is still a problem in 0.93.

[_mat_]

Amazing work, @0.0!

This shows exactly why security is important for competitive benchmarking. This is a completely different approach than my hacks in the past and even fools 3DMark perfectly!
As for the Geekbench 5 wrapper there is only one thing to say: ?

Thank you for reporting the Windows 7 bug. By using older platforms I could reproduce it as well and will look into it today and fix it asap.

I've also removed the "Keep best score" option in CINEBENCH R11.5 and R15 (only when launch via BenchMate), but I can't avoid this "feature" in R20. So I will add it to the "Known Bugs" list just to make sure the flaw is documented. This actually isn't a cheat because BenchMate will always capture the most recent score. But it could be confusing to see a higher score in the screenshot than BenchMate submits to HWBOT.

[_mat_]

@0.0

I've been playing with BenchMate on Windows 7 the whole morning and although I reproduced the problem once, I can no longer do so. It always "just" works, the freeze happened once for about 5 minutes, exactly like you had it, and then it never happened again. I tried many things, from using the Win 7 on other systems to changing the hardware. All of those needed cold boots of course, but it works with 0.9.3 (freshly downloaded) and the latest build (0.10).

Does this still happen on every cold boot on your install/sys?

[Guest 0.0]

I surprised myself that so many native benches are affected by that skew which is insanely easy to execute.

The bug happens once in a while and hard to reproduce, especially on an old slow laptop. A rare problem it seems as not seeing any other reports but am trying to do some more testing. When it comes out of the hang which now seems multiples of 5mins perhaps suggesting a system timeout / watchdog, it's as if everything is normal. No obvious error reporting but can give you what is shown under the event viewer.

Event App log
10:33:12    bmservice32 Error 0
10:33:12    bmservice32 OnStart
10:33:13    bmservice64 Error 0
10:33:13    bmservice64 OnStart

Event Sys log
10:33:06    bmrbt installed
10:33:08    service32 installed
Windows hang for exactly 5 minutes (no systemtime update during that period)
10:33:12    service32 running
10:33:12    service64 installed
10:33:13    service64 running
10:33:21    HWiNFO installed

Other notes:

HWiNFO driver left running on Benchmate exit, not aware of any other apps using it. Autoruns on reboot.

Closing Benchmate before fully initialized results in an exception being thrown.

 

After some task scheduler automation with Benchmate set to auto launch 2 mins after startup it appears to work as expected. Changing the time to 10 minutes though sees hangs every time, usually 10mins long. Running just the bmrbt64.sys driver using sc.exe sees the same hang when set to start. Hope this helps.

 

Edited September 16, 2019 by 0.0

[_mat_]

11 hours ago, 0.0 said:

The bug happens once in a while and hard to reproduce, especially on an old slow laptop. A rare problem it seems as not seeing any other reports but am trying to do some more testing. When it comes out of the hang which now seems multiples of 5mins perhaps suggesting a system timeout / watchdog, it's as if everything is normal. No obvious error reporting but can give you what is shown under the event viewer.

I will build some old systems and see if I can reproduce it there. It's a very weird problem, but only some platforms and Windows 7 are affected. I'm sure we are going to find the cause. Thanks for your input, very much appreciated!

Btw, another issue has been reported with CINEBENCH and realtime process priority. Scores run in realtime can't be validated due to a kernel bug. Please run with High priority instead to make valid results for now. I'm looking into it.

[cbjaust]

11 hours ago, _mat_ said:

I will build some old systems and see if I can reproduce it there. It's a very weird problem, but only some platforms and Windows 7 are affected. I'm sure we are going to find the cause. Thanks for your input, very much appreciated!

Btw, another issue has been reported with CINEBENCH and realtime process priority. Scores run in realtime can't be validated due to a kernel bug. Please run with High priority instead to make valid results for now. I'm looking into it.

do you mean the Shield with the green tick validated? I just ran CB R15 and R20 Realtime and got the green tick both times:

4241138_cbjaust_cinebench_r15_with_benchmate_ryzen_5_3600x_1748_cb

4241120_cbjaust_cinebench_r20_with_benchmate_ryzen_5_3600x_3933_pts

Also if you need older platforms tested, I'd be happy to help: My Hardware Library

Edited September 17, 2019 by cbjaust

[MrGenius]

Seems to be something going on with GB4 compute and BM on W7. That is trying to run it with my Vega 64. For some reason it will barely run the compute test @ stock(1663/945). Yet I can run it @ 1700/1200 on W10 with BM. And @ 1735/1215 on W7 without BM. The score with lower clocks and BM on W10 is also RIDICULOUSLY higher. ~50000 more points on W10 with BM and lower clocks? Seriously? Is it that messed up? That doesn't seem right. And not being able to run it overclocked at all on W7 is DEFINITELY not right.

Edited September 16, 2019 by MrGenius

[_mat_]

5 hours ago, cbjaust said:

do you mean the Shiels with the green tick validated? I just ran CB R15 and R20 Realtime and got the green tick both times:

4241138_cbjaust_cinebench_r15_with_benchmate_ryzen_5_3600x_1748_cb

4241120_cbjaust_cinebench_r20_with_benchmate_ryzen_5_3600x_3933_pts

Seems to be Intel only then, thanks for your testing. It's a very interesting bug though and basically another way to break one of the time sources by just using realtime process priority. But it's too early to say this for sure, or what impact it has.

59 minutes ago, MrGenius said:

Seems to be something going on with GB4 compute and BM on W7. That is trying to run it with my Vega 64. For some reason it will barely run the compute test @ stock(1663/945). Yet I can run it @ 1700/1200 on W10 with BM. And @ 1735/1215 on W7 without BM. The score with lower clocks and BM on W10 is also RIDICULOUSLY higher. ~50000 more points on W10 with BM and lower clocks? Seriously? Is it that messed up? That doesn't seem right. And not being able to run it overclocked at all on W7 is DEFINITELY not right.

Geekbench is no longer supported by BenchMate due to the legal threat. So whatever is happening here, I couldn't care less.

[MrGenius]

Point taken. And for the record...I've come to find out running GB4 compute without BM on W10 gives me a similar +50000 point score(compared to W7). So it's not BM with that at least.

Anywho...well...whatever I guess. There's something going on with it and GB4 on 7. Whether that's worth looking at might not have anything to do with supporting GB anymore. Maybe it would provide incite in general. I mean...it's broken pretty bad...whatever it is.

EDIT: I appreciate the correct usage of "couldn't care less". Really irks me that no one says that right. "Could care less"? Then DO! Nobody's stopping ya! ?

Edited September 17, 2019 by MrGenius

[Guest]

No one gives a fuck ... another way to say it 

[Guest 0.0]

14 hours ago, _mat_ said:

It's a very weird problem, but only some platforms and Windows 7 are affected.

The 300 Seconds was bothering me and after some thought makes a lot of sense now.

32-bit register wrapping and HPET frequency 14.31818MHz

2^32 / 14318180 = 299.966 seconds

On my system HPET is posted with 64-bit counter set and ACPI reports 64-bit (checked with UEFI shell) but when W7 loads it is changed to 32-bit (by OS ?). The upper 32-bits of timer 0 are masked to 0 but it still counts 64-bit. bmrbt64.sys when started changes bit 8 of TIM0_CONF to 64-bit mode which then unmasks the upper 32-bits of the timer 0 counter but this doesn't happen for the main counter which carries on with upper 32-bits still 0. So depending how many times the counter has wrapped around previously in 32-bit mode it may take some time before a periodic interrupt is generated from timer 0. If HPET has been running less than 300secs (5mins) then no wrap so no hang. If it's wrapped say 4 times before 64-bit mode is selected then it's going to take 20mins before an interrupt on timer 0 occurs. IOW the system will be hung for 20 minutes unless resorting to the power off switch.

Edited September 17, 2019 by 0.0

[Splave]

So the debate on bigblocks dual core r15 using benchmate being legit or not and where to put it I played with it myself. 

12 runs for each scenario. As you can see benchmate makes a better average while maintaining the same max! Slot machine time maybe coming to an end!

The realtime issue occured for me as well. It scored very high using it 1132-1133 but was marked invalid when I saved. Depending on what is done for realtime or if it's able to be solved we shall see but this certainly is more consistent without exceeding the previous max without benchmate. 

[Leeghoofd]

I sense suspicious score bugging and subbing with a 7740X while notes are on a 7700K   But thanks for testing sir.

For future purposes we might better to opt to enforce BM to be used for Cinebenches & Geeks on all platforms and OSses

[_mat_]

Thanks for the research, @Splave!
This is exactly what I expected by the changes I made. CB uses the same time source but the result is more precise and therefore no more slot machine. Results should be pretty stable.

A small update to the realtime priority issue: I'm currently looking into it and what happens here is that CINEBENCH (haven't found it anywhere else) brings certain kernel functionality (not related with BenchMate per se) to a stand-still. I takes a few seconds but then really kicks in. That also means no runtime hardware detection, which I think is a big no-no to push things forward. So I will disable realtime priority for CB in the next version. I know that this might lead to something like 5 points less, which is anticpated btw due to the hardware and sensor detection each second. I think that's the primary reason why it's faster.

14 minutes ago, Leeghoofd said:

For future purposes we might better to opt to enforce BM to be used for Cinebenches & Geeks on all platforms and OSses

I have already removed Geekbench support for the upcoming BenchMate 0.10. That one is gone for good for me as are the many days spent developing and refining the integration of GB.

As for enforcing BenchMate, I don't think that's necessary for all platforms. What would be necessary is to finally let BenchMate upload into the real benchmark categories. That would be a good step forward in the right direction.

[_mat_]

5 hours ago, 0.0 said:

The 300 Seconds was bothering me and after some thought makes a lot of sense now.

32-bit register wrapping and HPET frequency 14.31818MHz

2^32 / 14318180 = 299.966 seconds

On my system HPET is posted with 64-bit counter set and ACPI reports 64-bit (checked with UEFI shell) but when W7 loads it is changed to 32-bit (by OS ?). The upper 32-bits of timer 0 are masked to 0 but it still counts 64-bit. bmrbt64.sys when started changes bit 8 of TIM0_CONF to 64-bit mode which then unmasks the upper 32-bits of the timer 0 counter but this doesn't happen for the main counter which carries on with upper 32-bits still 0. So depending how many times the counter has wrapped around previously in 32-bit mode it may take some time before a periodic interrupt is generated from timer 0. If HPET has been running less than 300secs (5mins) then no wrap so no hang. If it's wrapped say 4 times before 64-bit mode is selected then it's going to take 20mins before an interrupt on timer 0 occurs. IOW the system will be hung for 20 minutes unless resorting to the power off switch.

Very nice find! I will go into details about this as soon as I have the time to look into it. Thank you VERY much, your input is priceless.

[Leeghoofd]

32 minutes ago, _mat_ said:

As for enforcing BenchMate, I don't think that's necessary for all platforms. What would be necessary is to finally let BenchMate upload into the real benchmark categories. That would be a good step forward in the right direction.

let me rephrase that for all platforms using Win10 and the BenchMate approved benches. Will Pifast, X265 and Y-Cruncher be added soon ?

For the integration keep me posted how it works out with the programmers, that is not my cup of teal....

[_mat_]

6 minutes ago, Leeghoofd said:

Will Pifast, X265 and Y-Cruncher be added soon ?

pifast is already done and working well. I'm currently fixing two open bugs and will continue with x265 and y-cruncher next, hopefully mathbenchmark as well if the developer wants it. As for wPrime, still no answer from the dev. Anybody has had contact with him per chance? Mail address would be a good start, I already tried the contact forms on their website.

Whatever the current status of benchmark integration is, I will continue to add more over time. We don't need to wait for that to go the next steps.

[PKKShadow]

Love all the work you're putting into this mat!

[_mat_]

I have found a workaround for using Realtime priority on CINEBENCH and still have perfectly validated scores. ❤️

Bugfix will come with BenchMate 0.10 as soon as possible.

[bigblock990]

@_mat_ Is it possible for BM to detect and display ES cpu? The pic Allen shared above is a 7740x ES cpu. Also is it possible to add bclk x multi, "nb freq" (cache/mesh), and command rate for mem timings to the result window? If this info can be added then maybe in the future we can get rid of the cpuz tabs requirements.

[_mat_]

That's a great idea! Will be available in BenchMate 0.10, you can find an ES marking right next to the CPU name:

Edited September 18, 2019 by _mat_

[Leeghoofd]

2 hours ago, bigblock990 said:

@_mat_ Is it possible for BM to detect and display ES cpu? The pic Allen shared above is a 7740x ES cpu. Also is it possible to add bclk x multi, "nb freq" (cache/mesh), and command rate for mem timings to the result window? If this info can be added then maybe in the future we can get rid of the cpuz tabs requirements.

if we want to replace CPUZ the benchmate, the score windows needs to double at least in size, (if not triple) in size for moderation

Edited September 18, 2019 by Leeghoofd

[bigblock990]

28 minutes ago, Leeghoofd said:

if we want to replace CPUZ the benchmate, the score windows needs to double at least in size, (if not triple) in size for moderation

Don't see an issue there, larger result window still less space than multiple cpuz windows

Can you list out the info you use for moderation, that is currently missing from the benchmate result window? Maybe its possible in the future for mat to add this info. 

[Leeghoofd]

in fact we need to see similar info as the CPU-Z CPU (type of CPU, family, socket, FSB Multi, Speed,...), memory ( total, main timings, uncore)  and mobo tab (brand and type of board) Benchmate already has most of it onboard

The above are required not only for moderation but also for other users to compare scores. The latter is one of the main reasons for the CPUZs

Edited September 18, 2019 by Leeghoofd

[_mat_]

I think that and even more information should be available on a validation page for each result, just like CPU-Z has it.

So we have to define:

• What needs to be on the screen? This should be only the most important information to get a quick look of what's going on here.
• What needs to be available on the validation page? This should be the place to show everything. Maybe some information is withheld and only available for moderators.