# Bootable Linpack Xtreme with Porteus Linux Released



## Regeneration (Sep 30, 2018)

Stress testing unstable PCs from within Windows always posed a risk of corruption to the OS registry and files. But now, thanks to Linpack Xtreme for Linux and the lightweight Porteus Linux, you can stress test without those worries anymore. The bootable version of Linpack Xtreme integrated on Porteus Linux is just 320MB in size to fit on CD/DVD/USB.

Porteus is a lightweight and portable implementation of the Slackware Linux operating system that can be installed on a CD/DVD, MMC/SD card, USB flash drive or hard drive. Once installed on the storage media of your choice, it can be run on almost any PC, giving you the power and freedom of Linux anywhere you go.

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.

*Instructions:*
1. Burn the ISO to a CD/DVD, or extract it to a USB flash drive and run the installer (x:\boot).
2. Boot from CD/DVD/USB.
3. Edit the file 'settings' to customize the stress test parameters. Define the number of runs, set problem size and leading dimensions according to the desired amount of RAM to be used:

11026 for 1GB
15825 for 2GB
22611 for 4GB
27818 for 6GB
32209 for 8GB
35000 for 9.6GB

4. Double click on run_stress_test or run_benchmark, select open and then execute in terminal.
5. Monitor temperatures from the taskbar (top right corner) or with the included run_sensors script.

*Notes:*
* Linpack's output will be saved in a file named results.txt.
* You can also stress test from text mode: login as guest, type 'mc' to launch Midnight Commander, navigate to the desktop folder, edit the file 'settings' and select the desired run script.
* The password for the root account is toor.
* The i586 version is meant for old hardware, it cannot access more than 8 threads and 2.5GB of RAM.

*Downloads:*
Bootable Linpack Xtreme with Porteus Linux i586 | Mirror #1 | Mirror #2
Bootable Linpack Xtreme with Porteus Linux x86_64 | Mirror #1 | Mirror #2


----------



## Regeneration (Oct 3, 2018)

When I was working on the bootable Linux version of Linpack Xtreme, I encountered something intriguing. It appears the Linux SMP kernel is a lot more sensitive to CPU overclocking then Microsoft Windows.

I use the following system for my experiments: Intel Xeon W3680 @ 4.2 GHz (145x29), ASUS P6T (vanilla), 3x 4GB G.Skill Ares F3 @ 2320 MHz (10-12-12-31 CR1), and Nvidia GeForce GTX 970.

All the power saving features were disabled (SpeedStep, C1E, C-States), high-performance power plan profile set in Windows, Turbo boost off, Hyper-threading on, LLC on and manual fixed voltage for everything.

The system successfully passed (with 0 errors) the following stress tests: 24 hours of Prime95 blend, 8 hours of RealBench, 12 hours of Linpack Xtreme, AIDA64, MemTest86, MemTest64 and HCI MemTest. In addition, I ran a light load stress test to ensure idle stability due to LLC.

Now this 100% stable system crashed within seconds after running Linpack Xtreme on Linux. Kernel panic followed by a reboot.

At first, I thought it was some kind of a compatibility issue, so I tried mocking around with the BIOS configuration, and then different Linux distributions, even previous versions, but without any luck.

Eventually, after hours of testing, I found a solution: raising the CPU voltage from 1.281v to 1.325v completely solved the problem and stabilized the system.

The CPU needed an increase of nearly 50mV to be stable on Linux.


----------



## hat (Dec 17, 2018)

Is something wrong? I saw in the other thread you're at version 1.1.1 now, yet the "Bootable Linpack Xtreme with Porteus Linux x86_64" link takes me to the Windows version, and if I go to the mirror I wind up with a Proteus install featuring Linpack Xtreme 1.0.0.


----------



## Regeneration (Dec 18, 2018)

Version 1.1.1 is a bug fix release for Windows.


----------



## josywong (Nov 24, 2019)

request for ryzen temp monitoring support


----------



## TheWickerMan (Feb 11, 2020)

How can I test 16GB of RAM? What should edit? How to edit?


----------



## Regeneration (Feb 11, 2020)

TheWickerMan said:


> How can I test 16GB of RAM? What should edit? How to edit?



Edit the file 'settings' and set problem size to 43000.


----------



## TheWickerMan (Feb 11, 2020)

Regeneration said:


> Edit the file 'settings' and set problem size to 43000.


Thank you.

I saw that Porteus uses 400MB of RAM, pretty lightweight.

Windows version works with 14GB option.


----------



## Regeneration (Apr 22, 2020)

Updated today to include support for AMD Ryzen 3000 series.


----------



## Octopuss (Apr 22, 2020)

Regeneration said:


> Updated today to include support for AMD Ryzen 3000 series.


But the ISOs are exactly the same...?

edit: Ah, only the direct links are the old files. Should be updated or removed.


----------



## Regeneration (Apr 22, 2020)

Octopuss said:


> But the ISOs are exactly the same...?
> 
> edit: Ah, only the direct links are the old files. Should be updated or removed.



Clear your cache. All major mirrors were updated.


----------



## TheWickerMan (May 16, 2020)

How much time does it take to complete the test? Whats an average estimate per 20 trials?


----------



## Regeneration (May 16, 2020)

TheWickerMan said:


> How much time does it take to complete the test? Whats an average estimate per 20 trials?



Depends on the "problem size", processor, RAM and clocks.

Default settings and latest hardware probably 30 minutes.


----------



## Octopuss (Jul 12, 2020)

What are other problem sizes I can use for different memory usage?


----------



## Octopuss (Dec 30, 2020)

Can you update this to the latest version please?


----------



## Regeneration (Dec 30, 2020)

Octopuss said:


> Can you update this to the latest version please?



Will be updated soon.


----------



## Octopuss (Dec 31, 2020)

Maybe update the first post with the basic link https://www.techpowerup.com/download/linpack-xtreme/ that includes all the version.


----------



## Jokii (Jan 11, 2021)

The bootable GUI Linux has some power saving/screen saving enabled, the screen goes dark after some minutes. This is bad, because if it freezes or throws errors you won't see it.
Is there a way to disable it? It should be disabled by default IMO.

EDIT: _xset s off_ in terminal seems to disable it. But I think I'll stick with the text mode, it seems to work just as well or better (the cycles are a tiny bit shorter).

Thanks for this tool, by the way. Haven't used it much yet, but at least once it found an error faster than P95 with Small FFTs.


----------



## Regeneration (Jan 12, 2021)

Jokii said:


> The bootable GUI Linux has some power saving/screen saving enabled, the screen goes dark after some minutes. This is bad, because if it freezes or throws errors you won't see it.
> Is there a way to disable it? It should be disabled by default IMO.
> 
> EDIT: _xset s off_ in terminal seems to disable it. But I think I'll stick with the text mode, it seems to work just as well or better (the cycles are a tiny bit shorter).
> ...


It is a bit of annoyance to move the mouse once in a while, but better than having permanent system tray burns on the monitor.


----------



## Octopuss (Jan 12, 2021)

Do modern monitors do that though? I bet they don't, or at least not after less than a few hours.
Besides, you can always turn them off.
Personally, I would remove it if it can cause errors (and thus wasting your time).


----------



## Ferrum Master (Jan 12, 2021)

Octopuss said:


> Do modern monitors do that though? I bet they don't, or at least not after less than a few hours.
> Besides, you can always turn them off.
> Personally, I would remove it if it can cause errors (and thus wasting your time).



They do also. On way smaller scale, but do.


----------



## Regeneration (Jan 12, 2021)

Octopuss said:


> Do modern monitors do that though? I bet they don't, or at least not after less than a few hours.
> Besides, you can always turn them off.
> Personally, I would remove it if it can cause errors (and thus wasting your time).


Yeah but in a smaller scale. Happened to me 1-2 years ago on ASUS VG248QE 144Hz monitor during stress testing.


----------



## Jokii (Jan 12, 2021)

What's the optimal amount of RAM to use for stress testing? You wrote somewhere that one shouldn't go above 35k size or ~10GB of RAM, is that still relevant? Or is it better to use the max amount available?
I'm using the bootable Linux text only mode (not Windows or the Linux GUI), so I assume paging is not an issue.

EDIT: compared 33k and 44k quickly: the latter has a higher GFlops score and higher power usage at the wall.


----------



## Regeneration (Jan 12, 2021)

Jokii said:


> What's the optimal amount of RAM to use for stress testing? You wrote somewhere that one shouldn't go above 35k size or ~10GB of RAM, is that still relevant? Or is it better to use the max amount available?
> I'm using the bootable Linux text only mode (not Windows or the Linux GUI), so I assume paging is not an issue.


That's relevant for old architectures.  The more, the merrier, unless you see some kind of negative impact.


----------



## Jokii (Jan 12, 2021)

Alright, thanks. Yeah I think ~44k is the sweet spot for 16GB. 45k doesn't run and 44.9k runs, but with lower GFlops.

Another detail I noticed is that being logged in as *root* produces slightly higher GFlopfs compared to *guest*. I think I ran enough tests switching back and forth to get statistically meaningful results, but I'm not quite 100% yet.
It could be that being logged as guest has some additional overhead.


----------



## Octopuss (Jan 12, 2021)

Is there any chance you could make it so that user has to enter memory size to be used instead of some meaningless number? This always confused the hell out of me and I had to google it up.


----------



## Jokii (Jan 13, 2021)

I'd also like to suggest a more streamlined setup, at least regarding the *text mode* in my case:
1. Automatic login at startup (as root).
2. Don't init/load unnecessary stuff, such as mouse drivers.
3. Let the user run the tests quickly, without having to alter the settings file, using commands/aliases like _stress 44k 20x_ or _stress 15000mb 20x_ (the latter would probably be more user friendly, especially for new users).

Also, for the test itself, you could perhaps add a counter next to each run/trial (on the left, like 001 002 ...), so that the user can quickly see the progress (useful for longer runs). A time stamp or time elapsed might also make sense, but I think it could make it look too cluttered.
But if any of this adds overhead that diminishes the effectiveness of the test, then don't. Thorough testing should be the first priority. Besides, most of the times when a test failed for me, the whole thing crashed completely, so any such indications would have been useless.


----------



## dwells (Feb 22, 2021)

I've been running into a weird issue with the bootable version that I haven't been able to make heads or tails of. I can run the Windows version with no issues with an overclocked setup, and it'll fail as expected with a bad OC and run for 8 hours no problem with a stable one and behave as expected.

However, when running the bootable build, I consistently have an issue where it'll run the first pass at the overclocked speed, then the CPU frequency will drop down to the stock boost clock for every pass after that. If I exit the stress test and restart it, I'll see that the reported CPU frequency is now the stock clock still instead of the OC. The passes won't fail, residuals will match, and nothing will freeze, but it'll be stuck down at the stock boost clock after that single first pass. This happens regardless of what voltage or clock speed I'm running. Even the lowest possible overclock of 100 MHz will result in this same behavior, even if I throw needlessly high extra voltage at it, too. It's not just a clock speed reporting issue either with the app, as querying as root with dmidecode or cat on the cpu_freq will show that the clock has indeed dropped and the Linpack performance will show lower flops on subsequent passes.

Any idea what could possibly be causing this? Maybe some sort of incompatibility with how Porteus Linux addresses my hardware (Skylake i5 6600K, Asus Z170 Pro Gaming, UEFI mode with "other OS" secure boot setting and CSM support disabled, fixed manual vcore)? I'm really scratching my head here, as I've been testing away at this for a while with every known good voltage and core multiplier I know of and the issue keeps happening regardless, but only in Linux, and always right away after one pass as soon as the CPU gets a chance to "breathe" for a moment before getting loaded up with pass two.


----------



## Regeneration (Feb 22, 2021)

dwells said:


> I've been running into a weird issue with the bootable version that I haven't been able to make heads or tails of. I can run the Windows version with no issues with an overclocked setup, and it'll fail as expected with a bad OC and run for 8 hours no problem with a stable one and behave as expected.
> 
> However, when running the bootable build, I consistently have an issue where it'll run the first pass at the overclocked speed, then the CPU frequency will drop down to the stock boost clock for every pass after that. If I exit the stress test and restart it, I'll see that the reported CPU frequency is now the stock clock still instead of the OC. The passes won't fail, residuals will match, and nothing will freeze, but it'll be stuck down at the stock boost clock after that single first pass. This happens regardless of what voltage or clock speed I'm running. Even the lowest possible overclock of 100 MHz will result in this same behavior, even if I throw needlessly high extra voltage at it, too. It's not just a clock speed reporting issue either with the app, as querying as root with dmidecode or cat on the cpu_freq will show that the clock has indeed dropped and the Linpack performance will show lower flops on subsequent passes.
> 
> Any idea what could possibly be causing this? Maybe some sort of incompatibility with how Porteus Linux addresses my hardware (Skylake i5 6600K, Asus Z170 Pro Gaming, UEFI mode with "other OS" secure boot setting and CSM support disabled, fixed manual vcore)? I'm really scratching my head here, as I've been testing away at this for a while with every known good voltage and core multiplier I know of and the issue keeps happening regardless, but only in Linux, and always right away after one pass as soon as the CPU gets a chance to "breathe" for a moment before getting loaded up with pass two.



Sometimes Linux ignores the BIOS' power saving settings (SpeedStep, C-states) and may require a special kernel switch to be disabled.

In the Linux boot menu, press on tab, and then type in: "intel_idle.max_cstate=0".


----------



## dwells (Feb 22, 2021)

Thanks for the reply. Tab at the pre-boot splash screen with the lighthouse image, right? Then space and then the Intel switch along with the other boot arguments, then enter?

It’s been a hot minute (over a decade) since my *nix and BSD days, so forgive the dumb question.

Assuming I did it right, no dice, I’m afraid. I am noticing that the sensors coretemp-isa-0000 command reports 80C as the “high” bound for the CPU, which is kinda low for Skylake. I’m also noticing that after that first pass, the temps never crack 79C. I think Porteus is still doing its own thermal throttling.

*EDIT*
Pretty sure I just figured it out and it is indeed a Linux issue! The conservative “high” mark of 80C (not sure where it’s getting this from, intel_pstate, maybe?) is being used as a throttle point.

By default, Porteus loads the powersave setting for the cpu_frequency_scaling governor. Not only does powersave save power, it also begins frequency throttling well before the detected “crit” limit for the processor, instead using the “high” limit. You can verify that the Linpack Porteus package is using powersave by opening the terminal and running:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

This will display the current governor (powersave) for each logical CPU core detected. To fix it, become root (in the terminal type su and hit enter, password is toor) and then overwrite the governor with the performance mode for every core by entering:

echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

To verify that the command worked and you didn’t mess up typing the path, run the cat command again, which should now output performance instead of powersave.

After doing this, my stress test runs are now consistent and my CPU OC is staying where it should be.

@Regeneration, from the brief research I did, I think the kernel flag to make sure it boots with performance enabled for the CPU is CONFIG_CPU_FREQ_GOV_PERFORMANCE


----------



## dwells (Mar 1, 2021)

Hey @Regeneration, whenever you update this again, any chance you could include Google’s stressapptest binary? I’ve been hopping between this package and a drive with Tiny Core Linux and stressapptest on it, but it would be nice to have the most demanding CPU stress tester _and_ the most demanding memory tester in one bootable distro.


----------



## Jokii (Mar 5, 2021)

@dwells: Just in case you don't know about it, I can recommend Ventoy or some other multiboot tool.
(Also, while I use and recommend GSAT bootable, I think TM5 with anta777 config is a more demanding memory test—but each one is different, so it's best to use several ones.)


----------



## dwells (Mar 5, 2021)

Thanks for the heads up, I’ve actually never heard of Ventoy! That looks awesome, I’ll have to give it a try today just to play with it. Seriously cool that you can just give it unaltered isos and it’ll multiboot them.


----------

