Mysticial
-
Posts
156 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Events
Blogs
Posts posted by Mysticial
-
-
played around with the benches last night. The wrapper is nice, thanks. But I did get a ton of the coefficient too large errors. It made a big difference by restarting after every error. I kept trying to run again after error and would get it again unless I massively downclocked but if I restarted and worked my way up slowly I kept the errors away. But had trouble doing more than 5.2ghz on stage 2 and 5.6 on stage 1. Will try swap mode later with different setup.
http://hwbot.org/submission/3188092_strong_island_y_cruncher_pi_25m_core_i7_5960x_0sec_776ms
That's interesting. It's almost as if the AVX unit can get "stuck" in some way that can only be cleared up by power cycling it. I don't know if drastically changing the overclock can actually power cycle the AVX execution units. But it's worth a guess since it is known that they turn off when unused (among other circumstances).
I can't say I've ever been able to push a Haswell that far. Both of my Haswell boxes are heat-limited to about 4 GHz. My 4770K will hit 90C under AVX2. And I'm not equipped (nor am I gutsy enough) to delid it. Given that I use these machines to develop this program, I'm basically "stuck" at these lame overclocks.
Btw, how much LN2 is the benchmark churning through?
The 5960X draws a lot of current under AVX-intensive loads. I'm guessing it isn't so bad for the 25m and 1b runs since they are short. -
I done my 10b run on sandy G470 single core with 4GB ram. works fine, just costs a couple HDDs...
Is swap mode going to be allowed in the future?
Not sure yet, I guess Mysticial will have an answer for this when he (and hwbot) evaluate beta results - glad you help at doing this by providing an unusual setup´s result
The new rules that I think I'm going to apply after the beta competition ends will be:
- Swap mode is allowed. But only if it was done in a contiguous run. So anything that used checkpoint restart will not be allowed. Checkpoint restart is a feature to facilitate extremely long running computations when the computer goes down due to power outage or a planned backup session. For competitive benchmarking it allows you to cheat by changing the hardware in the middle of the run.
- When running on Windows 8/8.1/10, the reference clock must be set to either HPET or ACPI.
- The digits need to actually be correct. Right now, y-cruncher will tell you whether or not they are correct. But it will output a validation file even if the digits are wrong. And the submitter will let you submit it regardless of whether the digits are right or wrong. This isn't a big problem right now because most errors will halt the program. So if it manages to finish at all, there's a high probability that the digits will be correct.
These new rules will apply starting from y-cruncher v0.7.1. And the submitter will enforce them.
Technically, the validations files produced by v0.6.9 have enough information in them for the submitter to enforce all of these except the HPET/ACPI. But that's extra work, so I'm just gonna defer it to v0.7.1 which makes the information more explicit in the validation file.
I'm in the process of feature-freezing v0.7.1 so that it will hopefully be ready for public release around the end of the beta competition.
I did it with swap mode, performances are so bad, it needs a lot of patience.Swap mode can be run efficiently. But you'll need a very specialized setup such as this:
- Swap mode is allowed. But only if it was done in a contiguous run. So anything that used checkpoint restart will not be allowed. Checkpoint restart is a feature to facilitate extremely long running computations when the computer goes down due to power outage or a planned backup session. For competitive benchmarking it allows you to cheat by changing the hardware in the middle of the run.
-
I think I must be missing something obvious, what's the data file we have to upload to take part in the competition?
You can't submit the datafile directly. You need to submit through the app itself.
Once you submit it to HWBOT, the app will open up a browser that lets you finish the submission. Somewhere during that process, there will be an option that lets you enter the score into the competition.
-
Win XP doesn't work
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.)
-
Glad you got it working and nicely done as well!
You have to run the wrapper with administrator rights to call bcdedit, am I correct? That's why I decided to just give a link to my FAQ section.
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.
I'm not really benching anymore so haven't bothered to test, but from what I can see the 25M test is kinda pointless?I wouldn't personally have that as one of the permanent benchmarks in the bot since it's already below a second on a 5960x.
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?
-
No kernel mode driver necessary. Just avoid certain timing methods on some windows version to avoid clock skew. I introduced this with GPUPI 2.1 and wrote a small article including some tests: https://www.overclockers.at/articles/gpupi-2-1
Let me know if you need any kind of help. And keep up the good work!
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.
-
Can you please xplain why I can submit with the hwbotsubmitter but same file I think cannot be uploaded at hwbot form?
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.
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.
-
damm impressive..with swap!
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.
-
Regarding the "coefficient too large failure" - it seems to be a stability issue for stages 1 and 2 (I only have 32GB so could not test stage 3). I got the same error with HPET on or off however, lowering the core clock one multi with all other settings the same, it passes. Load seems similar to p95 and current draw is very high on an 8 core. Is there something I'm missing?
Different question:
Stage 1 needs at least 195MB of ram, Stage 2 needs at least 4.8GB RAM... then stage 3 jumps to 46GB (so 64GB min with all channels populated the same on most platforms)? Bypassing the more common 32GB configuration? Very limiting for Stage 3 entries, no?
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.
-
Well can you implement a way to detect HPET like _Mat_ did with GPUPI ?
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.
- On my 4770K and 5960X, Win7 doesn't use it.
-
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.
- Disable HPET via bcdedit.
-
I managed to take only one measurement on the X99, when I detuned
the system below 4.5ghz.
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.
-
I have to ask again. maybe I am stupid
Running on RVE with 5960X and Windows 10 with Hpet enabled or disabled.
I get the message coefficient too high-Redundance too large to execute.
All three benchmarks.
Any help ?
Thanks in advance.
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?
George, please note that Pieter made a clarification on OS use for the y-cruncher, it is beta an we still need to learn so please use win7 unless you use skylake. On the coefficient question, do yu have enough available memory and is it stable?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.
-
No changes, and even the stock has hardwares that me also displayed.
Pi-25m goes smoothly
but Pi and Pi-1b-10B, its not want to know. every time I have the right to error.
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.
-
using 1366 here, haswell to new for me.
that errors i hit this morning on the r3e , overclock wasnt stable.
got a hp ml150 g6 board here with two xeon L5520,,need to test but, 12gb ram only , will it do swap on 2x300gb sas raid? the 10billion test..
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.
-
nice benchmark, nice stress test also, not so nice heat output
Everything that heavily uses 256-bit AVX will do that on Haswell. I presume not too many benchmarks use AVX.
Hello, I have a recurring problem, each time I run into Pi-1B or even 89%, I have the right to a message:Redundancy Check Failed: coefficient is too large.
an idea?
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...
-
win 10/server 2012 r2 allowed?
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.
-
The submitter says it can't detect a compatible version of Y-cruncher on all my computers.
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.)
-
swap mode, manually via the commande line.
But hell, it doesn't progress for a percent in 20min ... only semi-load iterations of "VST-PM" & Co.
What the point of these phases ?
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.
-
Hi ^^
Trying y-cruncher at the moment, congrats for the well integrated Hwbot wrapper !
25M and 1B done, i'm currently running the 10B ... see you the next decade
FX-8350 and 16GB, i put the bench on my hdd and enabled the swap mode.
Now, 54% completion for 1h11.
Just a question, y-cruncher use the disk where it is, or it use system disk ? maybe my ssd is getting raped x)
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.)
-
Hello
I nevertheless uses the latest version.
I do not understand?
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.
Math turns benchmark: y-cruncher meets HWBOT
in Benchmark software
Posted · Edited by Mysticial
I just pushed an update to the submitter app. The new features are:
Along with this are some miscellaneous UI changes. The top menu bar is largely redundant for now. It's a placeholder for later when there isn't enough space to make a button for everything.
The screenshots are sent as part of the datafile. Due to the encoding that HWBOT uses, the datafiles would be really large. So I had to turn on compression. In other words, the older versions of the submitter will no longer work. So you will need to update to this one to make any new submissions.
Hopefully this won't be too problematic for everyone. Please let me know if there are any issues with this new version. Quite a few things changed and it's possible I broke something.
Here's what the latest version looks like: http://hwbot.org/submission/3189606_