Linpack Xtreme Released

[Regeneration]

Linpack Xtreme is a console front-end with the latest build of Linpack (Intel Math Kernel Library Benchmarks 2018.3.011) developed and maintained by ngohq.com. Linpack is a benchmark and the most aggressive stress testing software available today. Best used to test stability of overclocked PCs. Linpack tends to crash unstable PCs in a shorter period of time compared to other stress testing applications.

Linpack solves a dense (real*8) system of linear equations (Ax=b), measures the amount of time it takes to factor and solve the system, converts that time into a performance rate, and tests the results for accuracy. The generalization is in the number of equations (N) it can solve, which is not limited to 1000. Linpack uses partial pivoting to assure the accuracy of the results.

Linpack Xtreme was created because Prime95 is no longer effective like it used to be. LinX, IntelBurnTest, OCCT use outdated Linpack binaries from 2012. Modern hardware requires modern stress testing methodology with support for the latest instructions sets.

Linpack Xtreme is available for Windows, Linux, and as a bootable media. The bootable version is considered to be the most superior as the Linux SMP kernel is a lot more sensitive to hardware instabilities than Microsoft Windows. Watch this video for a short comparison of Prime95 vs. Linpack Xtreme.

Make sure to keep an eye on the temperatures as Linpack generates excessive amount of stress like never seen before.

Changes (v1.1.8):
* Residual checks are now enabled by default for Intel processors without AVX2 support. Residual checks can forced or disabled by using the following command-line switches: /noresidualcheck or /residualcheck.
* Fixed a crash on AMD Zen 5 processors.
* Fixed a crash to desktop on AMD hardware.
* Fixed a error on recent OS installations without WMIC.
* Some bug fixes.
* Updated CPUID HWMonitor to version 1.55.

Downloads:
Linpack Xtreme for Windows | Mirror #1 | Mirror #2
Linpack Xtreme for Linux | Mirror #1 | Mirror #2
Linpack Xtreme Bootable Media

 

[AlwaysHope]

Has this been tested on all Intel & AMD current platforms?

 

[Regeneration]

It is intended for current Intel platforms. Don't have Ryzen system to test it on.

 

[hat]

What happens if it finds an error?

 

[AlwaysHope]

It is intended for current Intel platforms. Don't have Ryzen system to test it on.

No problem, I'll give it a go when I get a chance.

 

[Regeneration]

What happens if it finds an error?

You'll be notified, crash, or BSOD. But take in mind, this build of Linpack is very stressful for the CPU, watch the temps.

 

[hat]

You'll be notified, crash, or BSOD. But take in mind, this build of Linpack is very stressful for the CPU, watch the temps.

Just the way I like it. Does it halt on error though? Unfortunately, as my system has no OC capability, it would be silly to run it... but if I find myself at the helm of an overclockable system again, I'll be using this tool for sure. Got this page bookmarked.

 

[Regeneration]

Just the way I like it. Does it halt on error though? Unfortunately, as my system has no OC capability, it would be silly to run it... but if I find myself at the helm of an overclockable system again, I'll be using this tool for sure. Got this page bookmarked.

It *supposes* to halt on error

 

[robot zombie]

Ill try it on my 2600 system. Im finding IBT the most practical way to do preliminary testing. If anything is majorly wrong it has a way of letting you know quickly.

 

[John Naylor]

Gratz on the work .... always great to have another tool in the box so to speak. But I would like to encourage the community to consider tools that focus on creating an evern bigger heat / load than a;l; the other sythetic tests which produce conditions the CPU will never, ever see in it's useful life.

I guess the point Id like to speak to is related to the tool choices which are more relevant to how we actually use oir PCs. Most synthetic stress tests place a single task load on all threads on a CPU, the likes of which it will never see again. So is the goal to "creat the most severe torture test " ? Ot to create the most suitable test that represents how PC is used ? Yes, in engineering we create factors of safety such that we are absolutely sure than say a cable in a chain engine hoist doesn't break and kill someone, the greater the risk to life, the greater the factor of safety warranted.

But what is the risk here ? That someday under a certain combination of conditions, our PC might crash ? When overclocking, is it worth having my OC limited to say a 4.8 GHz, using LinPack or another stress test when using something real world application based I can easily sustain 5.0 ? To take it to the ridiculous, not many have responsibilities akin to putting NASA astonauts lives at risk because our PC is controlling their navigation and a crash might send them veering off into the sun.

There are many folks who enjoy the challenge of building a PC to run synthetic stress and trying ti do it better than others have done ... and proudly place their name on OC leader boards. But most of us build PCs to run applications. And for my goals, a stress test that tests in a mutitasking environment, using several extremely demanding real world applictaions (ones I actually use) at the same time is a more realistic, and therefore more useful, test mechanism. And yes, I have had 24 hour stable OCs which tested all threads with synthetic loads later fail when using a multitasking applications based benchmark for 40 minutes. If the OC can run apps, can't we be content with that 5.0 ... Do we need to know that we would have to drop to 4.8 cause it generates too much heat under OCCT, IBT, P95 or Linpack ? Relevance ? That's not how I make my living.

Again, not bashing the work ... offer my compliments to it for it in its own right. Just throwing out that for those folks who are out there working on such projects, many of us would welcome some forays into applications based testing, perhaps even suites w/ subsets geared to particular industries .... animation and rendering .... 2D and 3D CAD .... number crunching ... video editing, etc. As I have found int he past, sometimes with a number of threads running different types of tasks, using different modern instruction sets can present a condition which a synthetic might not produce.

 

[MrGenius]

I like it. Pretty sure I'll be using this instead of IBT from now on. Thanks for sharing!

 

[hat]

Gratz on the work .... always great to have another tool in the box so to speak. But I would like to encourage the community to consider tools that focus on creating an evern bigger heat / load than a;l; the other sythetic tests which produce conditions the CPU will never, ever see in it's useful life.

I guess the point Id like to speak to is related to the tool choices which are more relevant to how we actually use oir PCs. Most synthetic stress tests place a single task load on all threads on a CPU, the likes of which it will never see again. So is the goal to "creat the most severe torture test " ? Ot to create the most suitable test that represents how PC is used ? Yes, in engineering we create factors of safety such that we are absolutely sure than say a cable in a chain engine hoist doesn't break and kill someone, the greater the risk to life, the greater the factor of safety warranted.

But what is the risk here ? That someday under a certain combination of conditions, our PC might crash ? When overclocking, is it worth having my OC limited to say a 4.8 GHz, using LinPack or another stress test when using something real world application based I can easily sustain 5.0 ? To take it to the ridiculous, not many have responsibilities akin to putting NASA astonauts lives at risk because our PC is controlling their navigation and a crash might send them veering off into the sun.

There are many folks who enjoy the challenge of building a PC to run synthetic stress and trying ti do it better than others have done ... and proudly place their name on OC leader boards. But most of us build PCs to run applications. And for my goals, a stress test that tests in a mutitasking environment, using several extremely demanding real world applictaions (ones I actually use) at the same time is a more realistic, and therefore more useful, test mechanism. And yes, I have had 24 hour stable OCs which tested all threads with synthetic loads later fail when using a multitasking applications based benchmark for 40 minutes. If the OC can run apps, can't we be content with that 5.0 ... Do we need to know that we would have to drop to 4.8 cause it generates too much heat under OCCT, IBT, P95 or Linpack ? Relevance ? That's not how I make my living.

Again, not bashing the work ... offer my compliments to it for it in its own right. Just throwing out that for those folks who are out there working on such projects, many of us would welcome some forays into applications based testing, perhaps even suites w/ subsets geared to particular industries .... animation and rendering .... 2D and 3D CAD .... number crunching ... video editing, etc. As I have found int he past, sometimes with a number of threads running different types of tasks, using different modern instruction sets can present a condition which a synthetic might not produce.

Well, as for me, and others like me, I like to ensure my system is stable under any circumstances. I don't care if I can play games and encode video at 5GHz if it crashes under a stability test. It should never crash under any circumstances. If it does, it's not stable. Similarly, it's not stable if it passes the test and crashes in a game. That's why I run a few different tests to try to ensure as best as I can that it will be stable no matter what I do with it.

 

[Regeneration]

I've released a new version. Fixed a problem with affinity/thread allocation and added support for AMD CPUs.

I like my overclocked systems 100% stable. I've had enough annoyances from overclocking over the years: silent data corruption, random errors.

My word of advice: run Linpack with maximum memory overnight and ensure the system is 100% stable.

 

[AlwaysHope]

Ill try it on my 2600 system. Im finding IBT the most practical way to do preliminary testing. If anything is majorly wrong it has a way of letting you know quickly.

I think it depends on what level one uses IBT at, that is how much ram is allocated & how many runs. Back in the day when it was 1st released, the author claimed 10 runs of standard was good enough, but OC enthusiasts & those with a propensity for obsesseive compulsion will run it many times more than 10 & max out all their ram. Then run p95 for 24 hrs...etc...etc...

In the end it depends what level of stability one needs. I tend to agree with user "CJMitsuki" over on overclock.net > Link when he was asked about what stability tests to run on 2nd gen Ryzens. Imo, he seems to know his stuff going by his posts.

I've released a new version. Fixed a problem with affinity/thread allocation and added support for AMD CPUs.

Thanks, I'll use this version.

 

[delshay]

Well, as for me, and others like me, I like to ensure my system is stable under any circumstances. I don't care if I can play games and encode video at 5GHz if it crashes under a stability test. It should never crash under any circumstances. If it does, it's not stable. Similarly, it's not stable if it passes the test and crashes in a game. That's why I run a few different tests to try to ensure as best as I can that it will be stable no matter what I do with it.

I agree with you 100%. The best time to run a stress test is when ambient temperature is high, ie summer months.

 

[robot zombie]

I think it depends on what level one uses IBT at, that is how much ram is allocated & how many runs. Back in the day when it was 1st released, the author claimed 10 runs of standard was good enough, but OC enthusiasts & those with a propensity for obsesseive compulsion will run it many times more than 10 & max out all their ram. Then run p95 for 24 hrs...etc...etc...

Oh definitely. I dunno if I go that far, myself. My definition of preliminary is to start with 10 on standard. Not a guarantee in my book, but a good sign. If that passes I'll do 10 with RAM maxed. If temperatures look okay, I'll start upping how many runs I do until I'm satisfied. Maybe an hour, or maybe several... ...usually not much more than that. A couple of times I've done 12h. To me it's just going so far beyond anything I would ever put my CPU through normally. My real usage doesn't involve a lot of prolonged loads of that nature, though I see the benefit of establishing consistency time after time after time.

Honestly, even running them for extended periods of time, if I pull through the first 10 at maxed RAM, chances are good I'll pass as many as I want to run. In fact, I don't think I've ever had a long run fail on a config that already passed 10 or 20 at max RAM.

From there, I'll verify max temperature with Prime95. Over time, small FFT's seem better for showing problems there, but 24h seems excessive. That's too unrealistic for my tastes, for simply watching temps, anyway. I'm not doing 24h renders, or really 24h anything. I've never failed p95 after passing linpack - temperature determines pass or fail. And if it gets too high, it's back to the drawing board and then more linpacks. Probably not needed but I like to minimize temperature, even under lesser loads. More of an OCD thing than anything beneficial. But it probably does help stability.

Past that I'll run some other synths, a few realistic tests, benchmark, and call it a day. I've always done something like this and I've never had any stability issues or data loss. But it really does all start with linpacks for me. Just what's always worked for me and my usage

I guess I'm set in my ways. At some point I will try other methods and see if the results are better, but at this point there's definitely an obsessive component to it. Like, "Oh sure I passed 24h of P95, but could it pass a long run of linpacks?" It'd eat away at me if it didn't pass or I didn't try.

 

[Regeneration]

I've issued another update to this release. Now you can have unlimited runs, disable Windows' sleep mode (always annoyed me when stress testing), more RAM selection, and included (optional) CPUID HWMonitor for temp monitoring.

 

[Flyboy_6cm]

Uhhhm.

 

[hat]

Getting the same error here, too.

@Regeneration can't you just attach it to the OP?

 

[Regeneration]

Got it fixed. Can't attach it here, the file too big.

I keep getting positive feedback for this.

For the people with modern intel cpus.

Prepare to nuke your overclocks/VRMs/MOBO traces and et cetera.

Appears to be running ~10 harder than p95 29.4 small fft on my 6700k.Does 256bit-avx and fma and i guess will do avx512 on skylakeX.

Pulled 150W at 1.3v 4.5ghz and did actually crash my 6700k in 20 seconds.For 340 SP GFLOPS(VTune reported) it seems to use about 23GB/S of dram bandwidth which means it also stresses your dram some.

 

[Athlonite]

erm why not just update the LinPak Binaries in IBT as the actual program doesn't really care what binary version your using

 

[Regeneration]

IBT will not work with the latest binaries.

 

[MrGenius]

Not correctly anyway. It does something with them. But not what it's supposed to. I tried it too.

 

[Athlonite]

IBT will not work with the latest binaries.

Not correctly anyway. It does something with them. But not what it's supposed to. I tried it too.

Ah Ok I see it's just I remembered updating them for AMD CPU's and just thought why not update them with the newer binaries

 

[Regeneration]

Version 0.6 brings better error detection. Linpack will now stop and beep on errors.

On another note... I found it my memory OC isn't that stable after all... the new Linpack crashed on me.