Mysticial
-
Posts
156 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Events
Blogs
Posts posted by Mysticial
-
-
Uh oh... This doesn't look good. I also have one other confirmation on a different forum.
Other things to note: It doesn't always freeze instantly. I have a different Win10 installation that sometimes manages to survive the first FMA test only to crash on the second.
The crash doesn't reproduce in Linux, but the code for Linux is slightly different since it uses a different compiler.
-
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:
Single-Precision - 128-bit FMA3 - Fused Multiply Add: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.
- Ryzen 7 1800X
-
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.
-
Same intel crapy sensors seen by previous Gen. Delid will help to bring cores temp closer. 10c diff is at idle or load?
Delid a Broadwell-E? Aren't those soldered?
-
@Mysticial send me an email with instructions what you need to get Y-cruncher ready for Zen
Massman has chosen not to receive private messages or may not be allowed to receive private messages. Therefore you may not send your message to him/her.If you are trying to send this message to multiple recipients, remove Massman from the recipient list and send the message again.
I'll send you an email when I get home.
-
Well, it won't be able to run XTU since that's an Intel application.
But you will see the difference in benchmarks such as Y-cruncher and HWBOT x265 1080P/4K
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.
-
yes 0.9.5.107
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?
-
i seem to have run into this issue,
checking the file it does detect the memory config.
file attached
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?
-
i seem to have run into this issue,
checking the file it does detect the memory config.
file attached
Thanks for the report. I'll take a look when I get home tonight.
-
We cannot check hardware used at moderation atm... This makes things a bit hard for moderation and even harder for random results. The problem of this submission is not what you write, a screenshot is mandatory for the participation in the competition, and if you submit this screenshot under rig pictures instead of validation screenshot, you will not be able to particpate at the comp
- normal submission for ranking worked as you can see at the linked result. We are also discussing verification rules atm, the way screenshot is made and added causes some problems for temperature limited comps, we have controversy about thisOnce again, no server hardware at all. The sentence about hardware having to be released at start of the competition refers to unreleased, new desktop stuff. You cannot use a 1080ti now for example even if you stole one at NV lab
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.)
-
OK, what I overlooked but others saw... you have not taken the screenshot with the embedded screenshot tool of the benchmark, or at least you have no suzbmitted it as screenshot but as attachment like system picture. Because of this the submission does not mazch the competitions need for a valid screenshot and you can´t add it.
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.
-
How can i save data file for future submit ? drivers for lan doesnt exist under XP.
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.
-
PM ed you :-)
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.
-
Exactly.
Is there another way to submit without Hwbot submitter?
Cheers...
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.
-
Hi Guys....
i can´t submit any scores with hwbot submitter on Win 7 because the log Window don´t show me scores. .txt data file is still there
So whats wrong ?
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?
-
Over the years hwbot worked with bench manufacturers and made it hard to cheat. Is it possible to implement a clock reader in superpi? Just to show the max clock cpu reached during benchmark.
Sent from my LG-D722 using Tapatalk
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.
- All frequencies: CPU, cache, base clock.
-
Hello, I've playing little bit for the benchmark. And i have some question.
1. For HWBot submission, It's allowed to run the benchmark via standalone binaries instead of HWBot submitter launcher?
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.)
And It's allowed to use Screenshot created by another apps for making the datafile?Since both of them is possible for now, right?
In GPUPI / HWBot x265 saving the datafile will capture the screen & only the screenshot from datafile is valid.
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.)
2. The datafile is created by an TXT validation file + screenshot (or any images file
).And created when clicked 'Submit to HWBot', deleted by the apps after uploading.
It's possible to directly make / save (multiple) datafile (With Screenshot included) after benchmarking?
I mean, after the benchmark finished, there's no TXT validation file appear first. And the datafile created when I click 'submit to HWBot'. And screenshot is captured & included in the datafile directly when I click 'submit to HWBot'.
I'm aware, if you implement this idea the benchmark must run from the HWBot Submitter. And my first question above is no longer valid.
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.
orI'ts possible to make multiple validation file (TXT) created by the binaries, to make datafile, after the benchmark running?
Which is easier?
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.
My concern it's, we are talking on OCed system, that anything can happen suddenly. Corrupted TXT Validation file, problems when saving, crash, etc.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.
3. Why you make the datafile deleted after submitting to HWBot?I think it's better to keep those file. Make good datafile naming mechanism / scheme. Such as (preset - time.HWBOT). It's related to my idea in 2nd question.
I still can keep it by copying the datafile when it was made though. But it's useless for now since manual submitting doesn't possible.
4. Make manual submit possible.
Many integrated HWBot benchmark could do this, HWBot Prime, GPUPI, HWBot x265 or even XTU, etc. With no issue i think.
It's funny (at least for me) if you willing to submit from another computer you must copy the entire folder which contains the application, and run the apps on another system just for submit. In fact in the end we had to open the browser also to fill in complete submission data form on the HWBot web to finish the submission processes
Many thanks, regards.
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.
- You're not supposed to see the HWBOT datafile anyway.
-
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. - 1 billion digits: 41.844 seconds
-
QPC falls back in various ways depending on the hardware and OS version, it can be HPET, ACPI or even RTC. The timer resolution of QPC differs greatly as well so it's difficult to find out which timing method is currently in use. That's why I decided to avoid QPC, it's too unreliable for benchmark measurements. Read around the web, software like VirtualDub banned it as well.
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.
-
I've researched this topic for some days back when I was developing GPUPI and in my opinion the only available option is to ban TSC from 8 and 10 and only allow HPET there. Using ACPI as a timer if available is possible but depends on how it's done. I would not advise to use Windows' QPC functions for example.
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.
Ryzen 1800X - Instant system crash when running sequence of FMA3 instructions. Request for verification.
in AMD CPU Overclocking
Posted
For me yes. BIOS 0502 (February 28)
The BIOS and AI Suite show a vcore of 1.350. CPUz shows it as 1.550. And it also happens when underclocked to 2.2 GHz.
The Windows Event Log occasionally manages to record which core it crashes on. It's pretty random among all 16 vcores. There's no single core that it always happens to. IOW, I don't see any signs of weakness to a specific core.