Jump to content
HWBOT Community Forums

_mat_

Members
  • Posts

    1003
  • Joined

  • Last visited

  • Days Won

    41

Posts posted by _mat_

  1. 1 hour ago, ObscureParadox said:

    Unless I missed something, all Allen did was expose the weakness in the benchmark and how to detect it? Not exactly sure what's rich about that.

    Can't see anything wrong with it as well. If you find a way to cheat, publish a score and disclose the details in the thread. Mods will have to pick it up from there to make it work, no other way around it. Forcing the bot's hand, so to speak.

    • Like 2
  2. 9 hours ago, speed.fastest said:

    XTU actually is fun to bench, only if it support AMD and not only 2 seconds count for scoring. There is still no successor for SuperPi 32m for new platform, proper multithreaded & memory scales a lot! I only think is 3DMark11 Physics is only option for now to replace SuperPi 32m.

    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. :D

    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?

    • Like 1
    • Thanks 4
  3. 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:

    1626703302_hwbotx265-99_999.thumb.png.d963654b858eab52d9f52ff95aba95d8.png

    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.

    • Haha 1
    • Confused 1
  4. 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.

    xtu-dll-injection-example-to-redirect-ac

    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.

    • Like 6
    • Thanks 7
  5. Every bench works differently and therefor has different needs. There is nothing wrong with that.

    Knowing the benches, the hardware plus all these extra tricks like the right BIOS version/OS/driver/mod is exactly what overclocking is about. You know, Turrican was not a talkative person but if you asked him something very specific about a bench and a (old) platform he could talk a good while about all these little things, that showed why he really was that good. As I said, nothing wrong with that ...

  6. Nice find! This looks exactly like the problem that we have encountered. The only fact that doesn't fit are the PassMark numbers. They are even worse then those in my micro benchmarks for div and modulo.

    Well, it might be possible to write a fix that sets the MSR mentioned in the PassMark forum to enable the division unit again. If this were a new CPU generation, I would do it. But for seven year old CPUs this is just overkill.

    Btw the article also explains why an old BIOS might not work. Windows could be responsible for disabling the division unit no matter what the BIOS says. So I guess that's why Windows 8 and Windows 10 show no performance advantage with pre AGESA 1.1.0.3 BIOS versions. This might be true for Windows 7 as well when optional updates are installed. I didn't install everything on my test drive, just SP1 and nothing optional.

  7. It was never meant to run CPUs in the first place (hence the name), but I'm glad it is used with both.

    Yeah, OpenCL is a turn-off to say the least. But that will change soon with GPUPI 4.0. As you can see in the screens the native path is already stable and faster than OpenCL on all platforms. The reason why it's taking longer than anticipated is, that an early release without good SSE and AVX support will end up in the same dilemma as GPUPI 3.3. And I really want that AVX support. ?

×
×
  • Create New...