Multiple 9th Gen Builds at Stock Failing OCCT Linpack

[SteveOrlando]

1 hour ago, Falkentyne said:

Did you use the newest OCCT?

 

2 minutes ago, jerubedo said:

I use 5.1.0

 

Same here, 5.1. It's just what I had on my thumbdrive and I've used it for testing other systems just fine. 

[jerubedo]

Oh, interesting! I took a look at the changelog for OCCT, and look at this:

 

 

Version 5.3.5

• CPU:LINPACK : Fixed a bug where false positive could be reported in some (thankfully rare) cases
• Translations : Updated Korean language (Thanks again JaeHyung)

 

Now, at the time of writing my original post, the latest version at that time was 5.1.0 with 5.2.0 as the beta version, both before this fix. This SOUNDS promising and would also explain why a few people reported the same issue at the time.

 

@Falkentyne @SteveOrlando

[Falkentyne]

26 minutes ago, jerubedo said:

I use 5.1.0, which it looks like isn't the newest one anymore, but it's only a few months old. I can try the new 5.4.0 version, too.

 

I use the default settings myself, under the linpack tab, which is 90% RAM usage and the default size.

 

Also, 20 runs of 0.9.6 passed just fine, as seen here. I think I'll try 1.1.1 next and I'll keep you posted:

 

Nope.  You failed almost half the LinX runs
Besides the changlog, that could also explain why you were getting false positives.  In this case they may not be false.

 

LinX does not stop with an error unless a thread actually -crashes-. (Extreme instability)  If a residual is wrong (math errors, which is slight instabilty) it keeps going.

[Falkentyne]

39 minutes ago, jerubedo said:

Oh, interesting! I took a look at the changelog for OCCT, and look at this:

 

 

Version 5.3.5

• CPU:LINPACK : Fixed a bug where false positive could be reported in some (thankfully rare) cases
• Translations : Updated Korean language (Thanks again JaeHyung)

 

Now, at the time of writing my original post, the latest version at that time was 5.1.0 with 5.2.0 as the beta version, both before this fix. This SOUNDS promising and would also explain why a few people reported the same issue at the time.

 

@Falkentyne @SteveOrlando

I'm on 5.4.2, but your CPU doesn't seem to be stable.  Look at your LinX residuals.

In order for OCCT to be buggy, your LinX 35000 residuals MUST all be the same!

 

The "errors detected" is exactly that--a wrong residual.  Instability detected could be a crashed thread (even worse).

[jerubedo]

1 hour ago, Falkentyne said:

I'm on 5.4.2, but your CPU doesn't seem to be stable.  Look at your LinX residuals.

In order for OCCT to be buggy, your LinX 35000 residuals MUST all be the same!

 

The "errors detected" is exactly that--a wrong residual.  Instability detected could be a crashed thread (even worse).

 

Are you sure that residuals must be the same?? In running 1.1.1, the English UI says that each line item is a pass despite different residuals, and that the test on the whole is error-free. See here:

 

 

Additionally, I tested my old 4790K and it doesn't have matching residuals either at stock.

[Falkentyne]

What version is this?

I know that old versions of linpack will have wrong residuals on newer systems.

However Linpack 0.9.5 *must* have the same residuals.

 

If my CPU voltage is too low, the residuals will be different.

If my CPU voltage is far too low, the application will abort completely with "errors detected."

 

I'll do a few tests for you and show you.

This will take awhile.

 

[jerubedo]

15 minutes ago, Falkentyne said:

What version is this?

I know that old versions of linpack will have wrong residuals on newer systems.

However Linpack 0.9.5 *must* have the same residuals.

 

If my CPU voltage is too low, the residuals will be different.

If my CPU voltage is far too low, the application will abort completely with "errors detected."

 

I'll do a few tests for you and show you.

This will take awhile.

 

That is version 1.1.1 (November 2018).

[Falkentyne]

Ok I found out what's going on.

/residualcheck is only enabled on AMD CPU's by default.  It's disabled for legacy Intel CPU's, and the 9900K and 9700K were not released when this version of Linpack came out.

you need to open a command prompt and use /residualcheck, then you'll get some nice errors

 

run 1 without residualcheck:

 

 

Run #2 with /residualcheck

 

As you can see I'm clearly not stable because Gflops is too high and load vcore too low on this binary (2018).  I'm using 4.7 ghz, 1.20v, LLC=Turbo.  So I need more to pass this test.

 

So, I set bios voltage to 1.225v, LLC Turbo.  Ok so now I know what the correct residuals SHOULD be, but it still isn't fully stable.

 

[Falkentyne]

But LinX has no problems passing at 1.225v bios set, LLC Turbo.  The gflops are lower so that's probably why.

[jerubedo]

8 minutes ago, Falkentyne said:

But LinX has no problems passing at 1.225v bios set, LLC Turbo.  The gflops are lower so that's probably why.

Thanks for all the details. I have a lot to dig into!

[Falkentyne]

55 minutes ago, jerubedo said:

Thanks for all the details. I have a lot to dig into!

So since I was running out of temp headroom I switched to Auto vcore and set loadline calibration to Intel defaults, or a setting of "Standard" in the Bios (max vdroop--1.6 mOhms), giving me the most stability and best transient response, and used AC Loadline instead.  This allowed me to lower my VR VOUT.  With an AC Loadline of 0.95 mOhms, I got this (the minimum VR VOUT, at the highest vdroop is under the IR 35201, 1.127v in the middle tab.  I accidentally blocked the labels, but you can see it).

 

 

As you can see, it failed on the VERY last loop, but the program decided to end the test (since apparently, it error checks when the next loop starts, but all loops were completed).

Came VERY close to passing.  another 0.05 mOhms (for 1.0 mOhms of AC Loadline) would have passed this easily.

Not going to bother testing that at ACLL=1.0 mOhms as it's unnecessary.

 

Can you tell that the correct residuals in LP Xtreme and LinX 0.9.6 are the same ?
It's a math problem.  The residual is the solution to the problem.  So they must always match on a certain sample size (35000).

If they're different, a calculation error occured.  (like saying 256 * 256=65535 instead of 65536).

 

Don't feel bad about failing this.  Passing something like this is diamond level stability.  Only computers used in hospitals, military installations or doing cutting edge scientific calculations need to pass stuff like this.  Not even Prime95 29.8 FMA3 is this difficult.  (someone said that Intel uses this as core validation in their own labs).

 

*Edit*.

Tried 4.9 ghz, auto vcore and AC Loadline of 1.6 mOhms and standard vdroop (1.6 mOhm).

LinX had no problems passing.  LP Xtreme failed, probably because the gflops are higher so it's more unstable (faster calculations).

The temps and current draw speak for themselves. 

4.9 wouldn't pass LPX because the VRM target vcore before vdroop) is limited to 1.520v (and LPX needs a higher target VRM vcore to pass this), and the base VID (what you see at idle) which is boosted to 1.520v at full load by AC Loadline (there's a way to check this), but can't go higher.  AC Loadline is unable to push the target voltage higher with its mOhms->impedance->target voltage (before vdroop formula), so its limited to 1.520v ---> 1520 mv - ( 193 * 1.6 ) = 1.213v at 193 amps.  Enabling SVID offset would allow initial VID to exceed 1.520v (not sure how far), but that's unsafe load vcore (probably about 1.27v and 200 amps!) and dangerous heat.

 

5 ghz is even worse.  target idle vid (no load) is 1.474v (instead of 1.434v).  But the load vcore (With SVID offset disabled) winds up being the same as 4.9 ghz so the test crashes and burns   Meaning LinX actually crashes.  I actually tested this on accident once (in Prime95 AVX small FFT) by enabling SVID Offset without reducing AC loadline.  VR VOUT was 1.323v (!!!) at full load, set by AC Loadline, and VRM target voltage (before vdroop) was 1.65v (!) which dropped to 1.323v after vdroop.  CPU got to 105C in 5 seconds flat.  210 amps....

 

 

 

[SteveOrlando]

I am so lost now. So am I good or no? I've been running 5.4.2 OCCT now for many hours and no more failures. 5.1 failed very quickly with many errors. I do have mismatched residuals in LinX but the test reports as passing. 

[Falkentyne]

OCCT is less stressful than LinX 35000, and Linpack extreme.  (Linpack extreme is harder to pass because the gflops are higher for some reason, so the CPU is working even harder, even though LinX 0.9.6 uses new Linpack binaries, and LP EX's binaries were released before the 9th gen processors).

 

You need to use the parameter -residualcheck in the command prompt (or add it as a launch option if you aren't typing it in command prompt with -residualcheck at the end.  That or /residualcheck (it's in the readme).

Then it will give you an error if your residuals don't match.  (if only the last loop's residual doesn't match it just ends the test with "Success"--that's a bug).

 

In LinX, if the residuals are different the test is not stable.  Period.

Remember: these are math problems.  A math problem only has one solution.  The solution is the residual.  So they MUST match.  Each sample size should have a different calculation.

 

Keep in mind that these Linpack tests are the most stressful tests known to man.  Back when the original linpack binaries were released (and you had to run them with strange commandline switches before someone made a front end for them), the person who released them said they came directly from Intel, and they are used to validate their chips at maximum current and load, which is how they bin their processors.  That's why they are so hard to pass.

 

If you are not passing them, it simply means you are unstable at that current and that load, in that test.