Mysticial

Support for Windows XP was dropped 4 years ago. Version 0.5.5 was the last version that could run on XP. Unfortunately, only v0.6.1 and later is supported for HWBOT. In short, the latest versions can't run on XP because they make system calls which didn't exist prior to Vista. As far as performance goes, you need a minimum of Win7 SP1 to be able to run the AVX binaries. So even if you could run on XP, you can expect a slow-down of at least 2x compared to Win7 SP1 and later. (Assuming you're running on Haswell.)

If the submitter app is run without admin rights, the UAC will prompt you for it when you try to do anything that requires admin. I had to solve the problem of admin anyway since y-cruncher v0.6.9 requires admin to run. I did some dirty hack with VB scripts to get it to work in a way that was aesthetically pleasing. The bcdedit option won't be enabled until v0.7.1 launches. There's no point in doing it earlier since y-cruncher can't detect the clock yet. And it's probably just gonna encourage people to exploit it. Correct. The 25m is kinda pointless. It was the original alpha-testing size that I used to develop the submitter app in the first place. Other than that, it's really only useful to test if you are setup properly to submit to HWBOT. It'll probably go away after the beta competition. If we decide to keep it, there shouldn't be any points awarded for it. (at least that's my recommendation) ----- And with respect to the benchmarks becoming too short. Since these are fixed sized benchmarks, they will inevitably get shorter and shorter until it's pointless. So the small ones will get phased out and bigger ones added. It may seem a bit far-fetched, but I imagine that the 1b time will probably go under 20 or even 10 seconds in the next couple years. (Especially if Skylake Purley with AVX512 lives up to expectations.) Here's a screenshot that Shigeru Kondo sent me. (Shigeru Kondo is the one who ran the 5, 10, and 12.1 trillion digit Pi records.) He doesn't have an account on HWBOT, nor can he submit it since benchmarks from y-cruncher v0.7.1 are currently not accepted. But it destroys the current 1b record set with a 5960X on LN2. Can anyone beat this?

Hey! We haven't spoken in a while! Yes, I actually did get it work a few days ago: http://forum.hwbot.org/showpost.php?p=440475&postcount=50 And I was able to test it for the other clock as well: Unfortunately, I had to change y-cruncher itself to do this. So this won't be public for at least another month. And even if it was ready before that, I can't release it during the beta competition because the new version (v0.7.1) is faster and will break speed consistency. The QC process for new releases of y-cruncher is very long and drawn out. It usually takes months since there is zero tolerance for bugs that may affect the correctness of a large computation. I also can't easily back-port this thing back to v0.6.9.

Originally, it was because the datafile wasn't encrypted. So you could just edit and submit whatever you want. But that point is moot now since I got the encryption to work. But one problem remains: I haven't tested this so I can't confirm it. But by the looks of it, HWBOT doesn't try to verify if the datafile is actually for the right benchmark. So you can manually submit a 25m benchmark into the 1b category. That's a big enough loop-hole for me to simply disallow manual submissions for now. I could fix that by using different encryption keys, but that complicates things and it wasn't something I considered important enough to bother with.

I'm gonna leave this right here: HPET detection seems to work on all 4 of the machines that I've tested on. There's an additional hardware timer that I'm interested in testing, but none of my machines are suitable for that. So that'll have to wait. That's enough for the meantime. Too much programming means that I fall behind on my Anime... p.s. Don't hold your breath for what's in the screenshot. This required a change in y-cruncher itself. And therefore it will need to wait until v0.7.1 is launched. (That will take a while and I definitely will not do it before the beta competition finishes since it will break speed consistency.)

It looks legit AFAICT. 0.801 - 4933.9 MHz - 83.412 % CPU Utilization 0.817 - 5001.0 MHz - 72.329 % CPU Utilization Even though the clock speed of the top score is lower, it makes up for it with a higher CPU utilization. If you do the math, the computation efficiency of that top score is actually lower than the 2nd place. Unfortunately, the 25m benchmark is so small that it is highly variable and sensitive to the task scheduling. There's also noticeable difference between Win7 and Win8/10 just because Microsoft improved their task scheduler.

Call me fanatical, but that entire machine is custom-built to run y-cruncher's swap mode. It's sole purpose is actually to test y-cruncher through its development. It's got 4 versions of Windows, 3 versions of Linux, and absolutely nothing installed other than compilers and overclocking tools.

I guess that's starting to make sense now. I didn't realize that the gap between "stable" and "AVX-stable" is so large that you can be completely "stable", and yet fail immediately on any AVX. About the stage 3 size. I asked Massman about the 48 GB requirement, and he said he was okay with it since it forces people to run a large and stable memory configuration. Technically, you can still run it without enough memory if you use the swap mode. That basically turns it into hybrid CPU/disk benchmark. (@Massman, if you're interested in this, my favorite swap mode test is 100b. Takes about 12 hours on my 4770K @ 4 GHz with 16 hard drives. I run these almost every weekend for regression testing.) It's just a beta competition for now. We can adjust the sizes later. There's a very good chance that 25m is going to go away at some point since it's too small.

I can't find a way to detect the HPET directly. At least not without kernel mode drivers. But there is a way to do it heuristically from user space with normal access privileges. Unfortunately, it will be a while before I can fully test this. Both of my test machines have ASUS motherboards which don't have a BIOS option to disable the HPET and force Windows to use something else. And the only Skylake system I have is a gaming laptop (overclockable, but with limited options). One thing that makes things more complicated is that Windows doesn't consistently use HPET even when it is available: On my 4770K and 5960X, Win7 doesn't use it. Win8 uses it by default on my 4770K. Win10 doesn't on both my 4770K and 6820HK. (I haven't yet checked to see what happens on my FX-8350.) If I do a blanket requirement that HPET is enabled, then all systems which are ok without it (Win7, Skylake) would be collateral damage and a major inconvenience to turn it on. From a usability perspective I can add a button that will create a script that runs the bcdedit command to turn on HPET. But come on... A program that creates scripts which run themselves as admin and modifies the BCD? Sounds totally harmless. That will have absolutely no issues with virus scanners. None at all... Right now v0.7.1 has OS detection. So I can whitelist all of Vista and Win7 and require a hardware reference clock for Windows 8/8.1 and 10. But there's no detection for Skylake. And then there's the question of Linux. (Which I'm not even gonna try to solve since it's open sourced and anyone can just modify and compile their own kernel.) At this point we're well into the territory where anything that is built will probably fall apart on the next generation of hardware or software updates. So looking forward, I'll need to design this "reference clock sanity check" in a way that can be reconfigured on short notice. Whatever the case is, I'm not going to write a kernel mode driver. That's a big can of worms and it's not my area of expertise. Furthermore, it's too invasive. I'm already lifting the privilege elevation for v0.7.1 and I really don't want to revert on that.

I just tested this on my 4770K: Disable HPET via bcdedit. Reboot the machine at 39 * 104 = 4056 MHz Within the OS, set it to 41 * 99 = 4059 MHz Sure enough, the clock skew kicks in and y-cruncher is magically 5% faster. Furthermore, I wrote a small C++ program that tests 7 different timers. Every single one of them is fooled by the clock skew. That explains why almost every benchmark is vulnerable. This is pretty bad... There doesn't seem to be a way to access the HPET without kernel level access. Nor is there a way to reliably detect if HPET is disabled. I spent a couple hours playing around with the behavior of the various system and hardware timers and examining how they respond to the base clock changes. From that I could see a pattern which is strong enough for me to build a heuristic that can detect if someone is cheating with clock skew. But I'm not 100% sure it'll be free of false positives. I won't disclose my findings publicly. But if any staff members are interested, please PM me. If I don't come up anything better, this heuristic will go into y-cruncher v0.7.1.

Interesting, so you got it to work once (and only once) after you downclocked? Other than that, I don't see anything in your configuration which stands out. Btw, my real name is Alex.

You're the second person to hit this issue. So now I'm really curious because it's starting to point at a potential bug in the program. The program has been around for 7 years, and this problem is only showing up now with competitive overclockers. What changes have you made to the OS that normally wouldn't be in place for an out-of-the-box installation? You mentioned HPET. Anything else, special drivers? System configurations? BIOS? The coefficient thing is a redundancy check failure in one of the core algorithms. It should have nothing to do with the timings or the memory. Someone else on the other thread had the same problem and it was failing consistently even at stock. The fact that this has never been seen before strongly points at something that only overclockers do. Either way, it's something that should be fixed regardless and I'd need more information to be able to do anything. I have one theory that could cause it - and I suspect it is driver related. But I have no evidence to support it other than the fact that it seems to be only affecting that one algorithm (which is unique in one important aspect). On the topic of the HPET, that's something that I'm looking at right now since it seems to be the solution to fixing the base clock exploit on Win8/10.

I was going to ask for more details of your system. But then I noticed that you did manage to get a 1b score submitted. What did you change? I'm really curious since it really shouldn't be happening so I'd like to fix it (or at least do something about it) in future versions. Btw, someone else seems to be hitting the problem as well - which is why I'm concerned.

Yeah, the program doesn't really care what you're running on. In fact it doesn't even know. All it knows is a path. If you're interested to see what a "high-end" swap mode configuration looks like, here's my 4770K doing the 10b with only 32GB of memory. http://hwbot.org/submission/3178862_

Everything that heavily uses 256-bit AVX will do that on Haswell. I presume not too many benchmarks use AVX. Is this happening even when the hardware is completely stable? That error normally only shows up on hardware instability. The fact that you're seeing it so early (and consistently) suggests something is seriously broken. But nobody else seems to be hitting it... Did you do unusual tweaks to the OS? I can only think of two possible things, but I'm not sure if they're even possible...

That's probably a question for Massman. I would guess that the answer is yes for now since it's still a beta. So now is the time to identify any exploits with the benchmark. I actually don't know if y-cruncher is vulnerable to the base clock exploit/cheat. But I would assume yes. In any case, it would be difficult to reliably enforce a ban on specific operating systems since the validation files do not record the OS information. So if someone is inclined enough, they could run the benchmark in Win8/10 with the base clock exploit/cheat. Then reboot the machine into Win7, fake a screenshot and submit it. This will be fixed in v0.7.1 as it will record the OS version into the validation file. With that said, if anyone knows how to implement a high-resolution timer (in C++) that is resistant to the base clock exploit, please let me know.

How are you running it? It needs to be unzipped and in the same folder as y-cruncher.exe. (In reality, it actually parses the "Read Me.txt" file to determine the version # of y-cruncher that it's trying to interface with.)

The computation isn't really linear. It's divided up in to multiple blocks of unequal size. While it's possible to derive the % mark at the top level, it's almost impossible within each block. What you're seeing are the progress indicators deep within the computation algorithm itself. For the most part, those internal progress indicators are meaningless to anyone who isn't familiar with the algorithms that are used. I used to hide them prior to v0.6.1. But when you're running a really large computation that takes weeks, seeing a static "XX%" indicator for several days straight doesn't provide much in the way of positive reinforcement that the computation is still running. So I ended up turning them on in the public versions even if hardly anyone will be able to decipher its meaning.

Are you running 10b in "Ram Only" mode or "Swap Mode"? If you're running it through the submitter, it will be in Ram Only mode and it will thrash the pagefile. If you're running it in Swap Mode directly in y-cruncher, then it will use the default path unless you specify otherwise. (Even though Swap Mode uses the disk, it is much more efficient than the pagefile.) The default path will be wherever you double-clicked to open the program. So if that's your boot drive with the SSD, then yes it will be "raping" your SSD. Wearing out an SSD is possible if you're not careful. But this is mainly a problem for the really big runs. (A 100b computation will incur 20+TB of writes if you have no more than 32GB of memory.)

That's strange... It works for me. Since the version restrictions clearly aren't working consistently, I went ahead and disabled them. I added those yesterday because I wanted to blacklist v0.7.1 until it is released. (There are a few of copies floating around out there. And they are faster than v0.6.9, so it wouldn't be a fair to those with only v0.6.9.) I guess that probably explains why there haven't been any submissions lately... Oops...

Update: I finally got the datafile encryption to work. So that has been enabled along with a new version of the submitter. (v0.9.2.64) This also means that older versions of the submitter will no longer work. So you'll need to download the new version. With this, I also switched the benchmarks to public beta.

Correct. Only the submitter app is in Java. The main app has always been in C and C++. I chose Java for the submitter app because GUI and networking is a pain-in-the-ass in C++. (I also expected it to work out-of-the-box in Linux as well.) Yes, the validation file is the only thing that matters. So you can run the benchmark one machine, and transfer it to another machine to submit it. For that matter, any Pi computation to one of the supported sizes can be submitted to HWBOT. It doesn't have to be one of the benchmark options. You can use the custom compute menu to fine-tune the parameters. (Hint: The default parameters are often sub-optimal. So you'll probably need to do this anyway to get the best possible time.) In the future, I'm probably going to add one limitation in that the computation has to be contiguous. (So that you can't start a computation on a fast computer, pause it, and finish it on a slower one to make the slow one appear faster than it really is.)

Right, I haven't actually fixed anything yet with v0.9.1.61. All I did was add the logging. Thank you! That did it: A localization bug. Decimals were being converted with commas instead of a decimal point. And because of that the HWBOT server couldn't parse them. I just pushed out a fix for that. See if v0.9.1.62 works for you guys. I can't guarantee that's the only localization bug. But at least we're one step closer. And that would explain why it worked on all my machines.

I've just uploaded a new version (v0.9.1.61) that will output the datafile and the full error message when a submission fails. If it fails again, please send me the following files: (zip them up and attach here) error-response.txt error-datafile.hwbot Validation - Pi - 25,000,000.txt (or whatever you ran) Hopefully that will be enough for me to figure out what the hell went wrong. Unfortunately, that's the best I can do since I've been unable to repro the error on any of my own machines. (Btw, the datafile is encrypted. But it's being sent unencrypted to HWBOT since I can't get that to work.)

Thanks. Since this is happening with more than one person and HWBOT.org is stable atm, then it's a problem with the app itself. I'll push out an update (hopefully tonight) that will log the datafile and error message that HWBOT sends back.