Bootable Linpack Xtreme with Porteus Linux Released

[Octopuss]

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]

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]

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]

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]

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]

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]

@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]

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.