Mysticial

One of my internal benchmark applications is insta-hard-freezing on Ryzen. Ryzen 7 1800X Asus Prime B350M-A (BIOS 0502) 4 x 8GB Corsair CMK32GX4M4A2400C14 @ 2133 MHz Nothing is overclocked. Everything is stock. Windows 10 Anniversary Update When I run the Haswell binary from here: https://github.com/Mysticial/Flops/tree/master/version2/binaries-windows The entire system usually freezes when it gets to: Sometimes, it will make it past that, but it usually ends up crashing/freezing later on in the test anyway. For those who don't trust the binary, the program is completely open-sourced in that GitHub repo. If you have Visual Studio installed: Open the project, build the x64 Haswell binary, and run. For me this always hard freezes the computer: At all clock speeds. When running single-threaded, it happens to any core that I pin it to. The questions that I want to answer are: Is this specific to my setup? No - Confirmed by multiple other people. Is this specific to Asus mobos or an immature BIOS? If so, can it be fixed with a later BIOS? Is this an issue with Windows? The crash does not seem to happen in Linux, but that is with slightly different code due to differing compilers. Is this a CPU errata? (I hope not - however unlikely it might be.) --------------------------- Current Testing Status: All of these are running Windows, and are at stock settings or underclocked. Confirmed Crashes: 1800X + Asus Prime B350M-A (BIOS 0502) 1700 + Asus Prime B350M-A (BIOS ???) 1700 + Asus Crosshair VI Hero 1700 + Asus Crosshair VI Hero (BIOS 5803) (two sets of memory G.Skill + Kingston - also fails with overvolted SOC) 1800X + Asus Crosshair VI Hero (Windows 7) - Once pass, mostly failures. Confirmed No-Crash: none yet For those interested in the technical details, I'm getting hard freezes for all types of FMAs (128-bit, 256-bit, single and double precision). But for some reason, it only affects this particular benchmark. Other programs (like prime95 and y-cruncher) aren't affected despite using FMAs. --------------------------- Update 3/16/2017: As much as I had least expected this to be the case, this appears to have been confirmed as an errata in the AMD Zen processor. In other words, the last bullet on my list (and the most serious). Fortunately, it's one that is fixable with a microcode update and will not result in something catastrophic like a recall or the disabling of features. To everyone pouring in from the various news sites: The important part is that a user mode program should not be able to hard freeze the entire system. Because if it can (as is the case here), it makes it possible to perform DOS attacks. IOW, this errata is a security issue. Don't be fooled by the "Haswell binary". The benchmark is 5 years old and I've largely neglected it for the last 3. So I haven't updated it for Zen yet. Any processor will be able to run any of the binaries if it supports the underlying instruction sets. If it doesn't, the program merely crashes with an, "illegal instruction". Under no circumstances should a user-mode application be able to bring down an entire system.

This whole DDR4 shortage is not playing along well with the Zen demand. I did manage to get some 16GB sticks without paying an arm and a leg, but that sold out within hours after I ordered. At least I have a tracking # this time... So I think I'm safe this time. Why do smartphones need DDR4? The lower voltage?

I ordered a pair of cheap 2 x 16GB sets off Newegg on Sunday in preparation for Zen. Only to find out today that they oversold and canceled my order. I thought I had beaten the Zen rush by ordering early. But apparently, I wasn't early enough.

Delid a Broadwell-E? Aren't those soldered?

I'll send you an email when I get home.

It will be interesting to see whether Zen runs faster with 128-bit AVX vs. 256-bit AVX. For the Bulldozer family, it was the former. (Though Carrizo had 256-bit AVX pulling almost even with 128-bit.) It's also worth mentioning that Zen opts for separate FP-Add/FP-Mul instead of a native FMA. Zen's FP-Add and FP-Mul throughput is theoretically on par with Intel (under optimal conditions). But FMA will be half throughput and the same as the Bulldozer family. This is the first time I've heard of a processor that has a "slow" FMA. Everything else, Bulldozer, all Intel, even PowerPC - if it has an FMA, it has a fast FMA. And it *only* has FMA. FP-Add is just (A * 1 + B). FP-Mul is (A * B + 0). So all floating-point arithmetic is the same (in cost) whether it be FP-Add, FP-Mul, or FMA. This presents a problem for y-cruncher because all the FMA that is uses was done assuming it has equal cost as everything else. So I'm half expecting Zen to be better off with some of the older Sandy Bridge code - with possible modifications like narrowing down 128-bit AVX. Zen coming on March 2nd *should* give me enough to do get the hardware and get a Zen-optimized binary out in time for Pi Day (March 14th).

I know breaking NDAs is bad whether or not you're the one who signed it. I've personally received pre-launch benchmarks of chips before NDAs have lifted. So I knew that Gainestown would be awesome. And I knew that Bulldozer would suck - about a month before the news got out. But not once have I ever considered leaking the benchmarks. But in the case of Kaby Lake, let's be pragmatic here. Is there anything left to leak about Kaby Lake? I mean, because of this thread, I've been able to read all the reviews and I now have more information about the chip than I've ever wanted. So I can confidently say that Kaby Lake is going to be... meh. And that nobody really gives a crap because Zen is around the corner. :banana:

Just a heads up to any staff members who might want to know... I'm planning a March 14th (Pi Day) release of version v0.7.2 of the program next year. And it will not be speed consistent with the current v0.7.1 release. Let me know if this will cause any problems with any ongoing competitions that will cover that date. I can't say what the speed difference is since that isn't set yet, but it will be more than enough to trip up an ongoing competition. The date isn't set in stone and will depend on the stability of the program in the preceding month. But it is the date that I tend to aim for since it's Pi Day.

Well. That validation file works fine for me. I'm able to actually submit your score. So I can't reproduce your problem. Can you elaborate on exactly what the issue is?

That validation file works fine for me. The only thing unusual about it is that it's using an unrecognized platform clock. The newest version of the submitter will allow it, but older versions won't. Are you using version 0.9.5.107?

Thanks for the report. I'll take a look when I get home tonight.

Oh, I wasn't referring specifically to this competition, but the general submission rules for y-cruncher. A screenshot is still necessary to capture CPUz data. And even though screenshots have their known weaknesses, this is the best that can be done. But I was talking about the necessity of the including the submitter app window in the screenshot itself. (Which I'm arguing is useless since it doesn't provide any extra security and makes it impossible to submit from a machine that doesn't have Java installed.)

I have a few nits about the current rules: 1. Requiring that the screenshot be from the submitter app is completely unenforceable. That screenshot is indistinguishable from a system screenshot via the PrintScreen key. 2. Requiring a screenshot of the submitter app doesn't add anything nor does it make it more secure. It's easily faked by screenshot tampering. And all the information that it provides is already contained in the validation file which is included in the submission metadata. Since it's part of the validation file, it's part of the hash so it's tamper-proof. I'm not sure what in particular is interesting in the screenshot of the submitter. The program already enforces the platform clock. The score itself is handled automatically as part of the process. And if you have any doubts, just look at the metadata. The original validation file is hex-encoded in the metadata. So it can be extracted and re-validated. I'm willing to PM you more details if you're interested. y-cruncher's validation system is actually a lot more complicated than it looks on the outside. And even if the submitter is completely compromised (someone reverse-engineers the validation code), it's still possible to distinguish real submissions from fake ones. So while there would still be a mess to clean up, at least it's technically possible to do so without making subjective judgement calls on whether something is legit or not.

The program won't run at all on Windows XP. Support for Windows XP was dropped more than 4 years ago. You will need a minimum of Windows Vista to run the program at all. You need Windows 7 SP1 to be at all competitive since that's the earliest version of Windows that supports AVX. You'll want Windows 8 or 10 to get the best performance since the schedulers are much better. But to answer your question directly, you can transfer the validation .txt file and the screenshot to a different computer and submit from there.

Fixed rolled out. (HWBOT Submitter v0.9.5.107.jar) In addition to fixing the memory parsing thing. I've also relaxed the reference clock restrictions. Rather than explicitly whitelisting only HPET and ACPI, it now only blacklists TSC. This solves a problem on my laptop which uses some platform clock other than HPET and ACPI. Hopefully this won't cause any problems.

I found the problem. The submitter is bailing out when trying to read the memory configuration. DIMM: 4.00 GiB - - DIMM: 4.00 GiB - - DIMM: 4.00 GiB - - DIMM: 4.00 GiB - - It's supposed to look something like this: DIMM: 8.00 GiB - Undefined - CMK32GX4M4A2400C14 DIMM: 8.00 GiB - Undefined - CMK32GX4M4A2400C14 DIMM: 8.00 GiB - Undefined - CMK32GX4M4A2400C14 DIMM: 8.00 GiB - Undefined - CMK32GX4M4A2400C14 Java's String.split() doesn't behave the way I expected it to when the fields are empty. The submitter skips any file that it has trouble reading so that it won't error things which are not validation files. Since it had trouble reading this file, it thinks it's not a validation file. Hence why it doesn't show up. I'll roll out a fix in a bit.

No there isn't. The submitter is the only way right now. Can you PM me the validation .txt file? I'll take a look.

Can you clarify the problem? If I'm understanding you correctly, the validation file is there (i.e. "Pi - 20160916-194531.txt" ). But it doesn't show up in the submitter?

Clock readers are extremely difficult to implement. There is a lot of processor-specific code. And it needs to be updated with every new generation of systems. This is the reason why most benchmarks don't have clock readers - and when they do, it's often inaccurate. CPUz is one of the few applications out that can reliably read the clock speed. This doesn't apply to just the CPU frequency. Any sort of hardware monitoring is extremely difficult to do: All frequencies: CPU, cache, base clock. All voltages Most temperature sensors. Hardware timers: HPET, ACPI. I've personally tried to implement readers for these, but every single one of them requires kernel mode drivers. Which require specialized programming experience as well as driver signing and super-admin access to the machine. And then you have to update everything for every new processor or chipset and maintain a database for all of them which you care to support. CPUz can do that. Few others can.

Yes. The submitter already lets you do this, but you're also free to manually run them. You are also free to fully customize the settings from within the y-cruncher application itself. You aren't required to run the benchmark from the submitter. And for that matter, you may need to do this anyway since the default settings (as chosen by the submitter) aren't always the best. (I have a feeling that some people won't like this ability to over-customize the settings. Since it means it's not 100% about hardware anymore. Someone with a sufficient understanding of the program itself and how it works will be able to pick better settings for their hardware setup. But when the goal is to be as fast as possible, I consider that as part of the game.) The official rules say you need to use the built-in screenshot. But that's impossible to enforce since the built-in screenshot is no different from any other screenshot. (The submitter doesn't watermark the screenshot.) No it's not possible. The submitter is completely separate from the main y-cruncher application. This is by design and I have no intention to merge them. The y-cruncher application is primarily used outside of HWBOT and it has its own validation system. The submitter is only responsible for integrating with HWBOT. I admit that the integration is less than ideal, but it's the best that can be done without being too intrusive to the main y-cruncher project and with the limited man-power that I have. Can you rephrase that? I don't think I understand. The benchmark already makes a new validation file for every computation. And the datafile is made by the submitter - which is after the computation is done running. How is that different from any other benchmark? And isn't that just part of the game? Realistically speaking, if the overclock can pass a y-cruncher benchmark, it'll have a pretty decent chance of handling a screenshot as well. Forget about the HWBOT datafile. You aren't supposed to know or care about it. If you're seeing it at all, that probably means that a submission failed. And when that happens, it won't delete it so that you can send it to me as a bug report. Instead of the HWBOT datafile, you should care about the validation .txt file. With that (and a screenshot), you can submit from anywhere. Right now, manual submission is disabled because: You're not supposed to see the HWBOT datafile anyway. The server doesn't check if the score you submitted is to the right benchmark. In other words, you can submit a 25m score into the 1b bracket.

Btw, I've recently received some benchmarks on a 68-core (272 thread) Knights Landing Xeon Phi: 1 billion digits: 41.844 seconds 10 billion digits: 504.873 seconds As far as I can tell, these are world records for single-socket processors. And despite running at a stock 1.4 GHz, it edges out all the LN2 systems. It still falls short of the really big Haswell-E and Broadwell-E dualies. But the program is completely untuned for the Xeon Phi. So there's probably a lot more performance that can be squeezed out from just software alone. I won't submit these to HWBOT since they were done in Linux using the unreleased AVX512-CD binary. The rules currently require Windows with a screenshot. And I prefer to keep benchmarks of unreleased versions separate from the released stuff. The validation files for these with all the details are available from my website if you want to take a closer look. Just don't try to steal them and submit them to HWBOT. The submitter app can't distinguish a legit benchmark from one stolen from someone else. So it will actually allow such a submission.

I think we might be talking past each other. I'm fully aware that QPC varies depending on the clock. That's sorta the whole point of this discussion. It's easy (for me at least) to determine whether QPC is backed by HPET, ACPI, TSC, or none of those. But you implied in your previous post that QPC is vulnerable to skew when backed by ACPI.

ACPI + QPC is vulnerable to clock skew? I admit that I have no way to test this since the only box I have that lets me disable HPET (to force ACPI) is my AMD box - which isn't affected IIRC. y-cruncher uses more than just QPC. So even if QPC gets skewed, it theoretically should still be okay. I can PM you the details if you're interested. Either way, I have no way to test this.

I'd like to bring back the topic of HPET platform timers and open up a discussion about virtual machines (VMs). y-cruncher submissions to HWBOT currently require either HPET or ACPI for Windows 8 and 10. But I've come to realize that there are other platform clocks out there. When you use bcdedit to force on the platform clock, you're not guaranteed to get either HPET or ACPI. My very own laptop seems to use an unknown platform clock which I've been unable to identify. Since neither y-cruncher nor the HWBOT submitter is aware of this clock, it blocks me from submitting benchmarks from my laptop. The broad problem is that only the TSC clock is affected by the clock skew on Windows 8+10. Does anyone mind if I change clock enforcement to blacklist TSC rather than whitelist HPET and ACPI? This should allow all other platform clocks. The downside of this is that it also allows VM clocks. Some of the Linux benchmarks that I've gotten from people use the "xen" VM clock. But that seems to be mostly a Linux thing. VMs in general are difficult to tackle since they (by design) attempt to trick the software into thinking it's running natively. So everything from clocks to instructions can (theoretically) be faked. y-cruncher v0.7.1 will attempt to detect if it's in a VM. But it currently doesn't block VM benchmarks because: They aren't a problem right now. I'm not aware of anyone using customized VMs to cheat benchmarks. The VM detection is not 100% reliable since VMs intentionally make themselves difficult to detect. Speaking of Linux, the submitter currently does not block any Linux submissions regardless of the reference clock. So you are (technically) allowed to run benchmarks in Linux, take a screenshot there, then transfer the files to Windows and submit to HWBOT. But given that there's no CPUz for Linux, this probably won't work for the majority of the competitions.

Errors in the console usually mean hardware instability. The most common one is "coefficient is too large". I don't know what chip you have, but the usual case is a Haswell chip that is stable enough for normal applications and "light" benchmarks, but not stable enough for AVX. This creates the impression that the program is buggy when in reality the hardware was never stable in the first place. Haswell with AVX-stability is by far the most common case. But I've seen it on other chips as well. My AMD box gets this a lot when I try to run my 1866 memory at stock. The IMC limits it to 1333, so 1866 is technically an overclock. But y-cruncher seems to be the only app that can expose the (slight) instability at 1866 MHz.