Hardlimit test bank

[cobito]

News

There is a new version of the program that speeds up the start time. In return, the initial screen only shows the stock frequency. To see the real frequency, you have to validate the result. We have managed to get the real frequency to have an error <3%. It is recommended that there are no other programs running during the test (not even CPUZ or similar).

The central has also received changes. To know them, you can see the first post of this thread.

In addition, a top10 has been added for mode 0. This top is only for the brave who want to compare their micro one-on-one without fancy sets that inflate scores excessively. I invite you to pass the bench in mode 0 unless you are a chicken

For now there are only 6 results in the ranking of mode 0 with pretty old micros, so you have it easy to appear.

[krampak]

I have tested Mode0 with the E5-2620V4 but the calculated speed is 1.78Ghz, I am not sure if the CPU does not really go up to the theoretical 2.1Ghz or if it is an error in the benchmark meter.

Edit: It seems to be a problem with the test, as it does not capture the maximum frequency that the CPU reaches (although it also does not show the one it has at rest, rather an average):

[cobito]

@krampak The performance graphs of that result have some brutal ups and downs. Something is happening on that PC that is interfering with the program. If during the frequency measurement it has caught one of those downs, it will not show the real one.

In fact, the mmt ratio indicates that there is something running in the background that is consuming quite a few processor cycles.

[krampak]

@cobito said in Hardlimit test bench:

@krampak The performance graphs of that result have some brutal ups and downs. Something is going on in that PC that is interfering with the program. If during the frequency measurement it caught one of those downs, it won't show the real one.

In fact, the mmt ratio indicates that there is something running in the background that is consuming quite a few processor cycles.

There is a resident antivirus that I can't deactivate. I guess it must be that.

PD: What a lunch the Ryzen has had in mode0...

[krampak]

@cobito On an i5 6500 it just gave me 6Ghz of calculated frequency... and curiously (I don't know if it's a thing of the new version) it has surpassed the old result of the i5 7500.

https://bm.hardlimit.com/result.php?bm=9796222558dc06a8a250c56af2a06753144

[cobito]

@krampak What is the real frequency? This weekend I will make the last change of the season, to see if I can close the topic of the frequency once and for all.

The code of the test bench has not changed (nor will it change in the future without a very good reason), so if it has given more it is because it has performed better.

[krampak]

@cobito said in Hardlimit test bank:

@krampak What is the real frequency? This weekend I will make the last change of the season, to see if I can close the topic of the frequency once and for all.

The code of the test bank has not changed (nor will it change in the future without a very good reason), so if it has given more it is because it has performed better.

Well the real one would be 3.6Ghz at most (turbo), it is an i5 6500 (without K). When I finish the d*** Windows 10 update I will test it on another i5 7500. I also have a laptop with an i7 6560U that I will test in the afternoon.

[Xevipiu]

The day before yesterday, at 4.25Ghz, the MAD gave me 4.5Ghz

[cobito]

@Xevipiu Ok, the source of the failure should be the same as that of krampak. The more modern the processor, the more screwed it is. I have a solution in mind that I hope will work.

By the way @krampak, I've seen the result of the 7500 and that of the 6500 and notice the mmt ratio of the 7500: in tests 1 and 2 it gives around 0.8. That's very low for not having Hyperthreading. In contrast, the 6500 comes out above 0.9 in all cases (except test 3) which are normal values (for not having HT). Just like in yesterday's Xeon, in that 7500 you have something consuming CPU when the benchmark is running; that's why it gave a worse result than the 6500.

Basically the mmt ratio should give above 0.9 (close to 1) in micros without HT and above 0.5 in micros with HT. If it comes out less, something is interfering.

[krampak]

@cobito said in Hardlimit test bench:

@Xevipiu Ok, the source of the failure must be the same as that of krampak. The more modern the processor, the more fucked it is. I have a solution in mind that I hope will work.

By the way @krampak, I've seen the result of the 7500 and that of the 6500 and look at the mmt ratio of the 7500: in tests 1 and 2 it's around 0.8. That's very low for not having Hyperthreading. In contrast, the 6500 comes out above 0.9 in all cases (except test 3) which are normal values (for not having HT). Just like in yesterday's Xeon, in that 7500 you have something consuming CPU when the test bench is running; that's why it gave a worse result than the 6500.

Basically the mmt ratio should be above 0.9 (close to 1) in micros without HT and above 0.5 in micros with HT. If it comes out less, something is interfering.

Now it has come out at 0.96 (except test 3 which gives very little), even so there is very little difference with the 6500 despite taking out 200Mhz and a generation. I'm talking about Modo0, I can't compare the other because I've passed ModoVI to the 7500 (after seeing that Xevipiu passed in VI, now I understand so much difference. If I can, I'll go passing VI to the old ones).

[Xevipiu]

@Cobito The MAD can fail due to its multiplier that scales from x0.25 to x0.25, for example: 100.4 x 40.25 = failure yesterday its real frequency reading.

Also, when the application starts, it doesn't read the real one, but the startup one

I hope it helps you

[Fassou]

@cobito Data from the last test on hlbm.exe 1.0.5

https://bm.hardlimit.com/result.php?bm=49474e66f4e94dce583921ba03045b73153

Summary:

3200Mhz nominal of the model Vs 3199Mhz in app
3600Mhz by CPU-Z Vs 3611Mhz in HLBM Central

Much more approximate :thumbsup_tone1:

[cobito]

There is a new version that I hope will fix the frequency measurement errors. I think it is calibrated a bit low (maybe it gives you a measured frequency slightly below the real one). I don't have PCs on hand to be able to do all the tests I need, so over time I will correct it.

[cobito]

Bueno, after testing the latest version with various platforms and generations, the frequency reading should work correctly in any scenario (with an error <3%). If there is nothing very serious before next week, there will be no more changes this summer.

[cobito]

Performance statistics have been added to the datasheets for each model. You can see an example here.

[Xevipiu]

Much better now.
Is there a way to output the LOG of all processes while they are running?

[cobito]

@Xevipiu In the first post of this thread you can see that it is at the top of the list of things to do. I have my reservations about giving details during the execution but sooner or later there will be at least some information about the progress. The when is what I don't know.

[Namiga]

Hello very much @cobito and other users...

I just passed the latest version on my I7... and I see very strange things...

I'll pass you a screenshot.
The one on the left is with the Antivirus activated (BitDefender), the ones on the right, consecutive and antivirus deactivated...

Very variable results...

What can this be due to?

Best regards

[cobito]

@Namiga It looks like there's something besides the antivirus that's sucking up processor power. You can try opening task manager > show processes from all users and sort the list by "CPU" usage. When you're running the multi-threaded test, there will be 8 hlbm-core processes each consuming 12-13%. The rest of the processes should consume 0. If during execution you see that some other process is taking time away from some hlbm-core, there you have the culprit.

[Namiga]

@cobito said in Hardlimit Test Bank:

@Namiga It looks like there's something besides the antivirus that's eating up the processor. You can try opening task manager > show processes from all users and sort the list by "CPU" usage. When the multi-thread test is running, there will be 8 hlbm-core processes each consuming 12-13%. The rest of the processes should consume 0. If during execution you see that another process is taking time away from any hlbm-core, then you've found the culprit.

Well, as always :), you were right...
I just ran it again and it gives me better values than before... I had to close some widgets, Dropbox and Drive... and there's a task from the Intel Management system... that I can't close and that can eat up to 10% of the CPU...
But even so, the multi-thread Test 3 doesn't come out well precisely.... 6671

but improving...

Thanks

P.D.: By the way... Does the central give good results?? I say this because in Monothread the maximum is 47709 from Xevipiu and my i7 gives 42419 and I don't appear in the Top 10... but if an E8400 does