• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

Linpack Xtreme Released

With version 0.9.3, AMD Ryzen users can now bake their CPUs like never before. Thanks to .vodka from AnandTech forums for beta testing.
 
Here with latest build:

Untitled.png
 
Linux users and anyone who would like to stress test outside of Windows can now use the new Linpack Xtreme package for Linux.

It's not the same like the Windows' version, but hey that's better than nothing.
 
A bootable version of Linpack Xtreme integrated on Porteus Linux is now available. Just 300MB in size to fit on CD/DVD/USB. Errors should appear faster since Linux SMP kernel is more sensitive to overclocking instability.
 
having a small bug with a Ryzen 2700X and Windows 10 1809

linpack_xtreme_bug.png

It detects 16 CPU's :D it should be 1/8/16
 
Incomplete detection on non-Intel CPUs is a known limitation.

Linpack originally designed to work only with Intel CPUs.

It should work perfectly on non-Intel CPUs as long as it detects the correct number of threads.

Everything seems to be in order according to your screenshot.
 
Regeneration said:
Incomplete detection on non-Intel CPUs is a known limitation.

Linpack originally designed to work only with Intel CPUs.

It should work perfectly on non-Intel CPUs as long as it detects the correct number of threads.

Everything seems to be in order according to your screenshot.
Click to expand...

it's a windows thing, cause on linux it detects well.
 
Linpack Xtreme v0.9.4 is now available.

* Improved thread affinity.
* Disabled HT/SMT on the benchmark mode.
* Updated CPUID HWMonitor to version 1.37.

Benchmark results are more accurate and efficient.
 
Last edited:
So, actually using this tool right now. It succeeded in crashing a messed up computer. Yay! I made some changes and running the test again. If it checks out, FWIW, this means that Linpack Xtreme broke a system that Memtest86+ failed to find issues with (even though that only ran for 3 passes...).

Got a few questions though. What's the difference between testing 2GB, 4GB etc? And why the limit at 9.6GB? Shouldn't ALL the RAM be tested, or does it all get tested eventually even with a small size like 2GB on a system with a huge amount of RAM like 128GB?

Also, if I may make a feature request: how about a counter that, erm, counts how many passes it has completed?
 
Last edited:
RAM selection defines the size of the mathematical equation to solve.

Solving a problem size above 35,000 (RAM usage of 9.6GB - 12GB on most systems) reduces the stress efficiency. Therefore, it is not recommended.

On systems with 128GB, it will automatically adjust to use more RAM.

Linpack does stress the RAM and uses a lot of bandwidth. However, Linpack, Prime95 and rest of system-wide stress testing applications cannot detect minor RAM errors since both CPU and OS attempt to correct such errors on-the-fly even without ECC memory modules.

Linpack will catch most RAM issues, but MemTest64 and HCI MemTest are more suited to test for RAM errors and more likely to detect even minor ones.
 
Last edited:
I just found this great thread today, bookmarked just in case I accidentally build a new overclockable PC
 
Let me give a feedback about various issues with this tool, after experimenting for a day.

My system:
  • MSI X399 MEG Creation
  • AMD Threadripper 2950X (stock)
  • CPU cooling - Enermax Liqtech TR4 II RGB 360 with push-pull on front inlet fo the case
  • Case Fractal Define R6 USB-C Blackout,
  • Memory: 4x 16GB DDR4 UDIMM ECC (Samsung M391A2K43BB1-CRC - advertised by Samsung running as DDR4-2133, 1.2V, but my BIOS by default will run it at DDR4-2400, 1.35V), overclocked to 2933 MT/s, tCL=18 (12.3ns) in quad channel configuration
  • Linux 4.18.10-2 (gcc 7.3.0-29).

Problems:

  • The LinpackXtreme.tgz file is malformed:
    Code: 
    $ tar xf ../LinpackXtreme.tgztar: A lone zero block at 61218
$
  • The executable files runme_*, xlinkpack_* don't have proper permissions set, i.e. they lack executable bit set (they should be 0755 in octal).
  • LinpackXtreme.tgz is not packed correctly, and extracting makes it put files into current working directory. This is undesirable, and any respected tool that have more than one file should instead unpack to subdirectory (i.e. linpack-xtreme-1.2.3, aka with name, no spaces, and version included)
  • The LinpackXtreme.tgz is unversioned. I.e. neither distributed file has a version in it, nor there is changelog, nor the binary shows version and date.
  • Distributed archives do not provide checksum (i.e. SHA256SUM)
  • .tgz suffix is rather old way of naming archives. .tar.gz is much cleaner and used around the in the wild.
  • There is no source code or build scripts!!
  • license.txt file contains weird unprintable characters
  • readme.txt file uses non-UNIX line ending format
  • There is no information which compilers and libraries were used, by investigating binaries I believe _intel64 is build with at least old year ICC, and _amd64 with pretty outdated gcc, and some sub-libraries even are few years old at least.
  • There is no indication if _amd64 binaries use function multi versioning, whatever they automatically select code paths depending on available cpu features (387 FPU, SSE2, AVX, AVX2, FMA3, etc), or there is a way to override this autodetection
  • There is no information if _amd64 binaries used hand written assembly, BLAS/ATLAS, or autovectorization for the main computational kernels.
  • The tool doesn't tell if the computations are done in single or double precision, and if in single precision, what kind of accumulation techniques for dot products are utilized (i.e. extension of accumulator to double precision, Kahan summation, etc)
  • Binaries do not set affinity properly for individual threads
  • Between each pass there is substantial pause (~1 second), or work done by one thread only, that allows CPU to recover thermally
  • Default 20 passes is not enough to make system reach thermal steady state, especially with water cooling systems
  • _intel64 binary does not run on Ryzen CPUs. Big issue.
  • It fails (only 145% of CPU used, instead of 3200%, probably live spinning forever on mutexes, and fails to actually run benchmarks) when run under strace -e trace=!futex, suggesting a race condition in barriers implementation
  • report.txt is overwritten by each run. tee -a report.txt would be better, or report_$(date --iso-8601=seconds).txt would be a better alternative.
  • It uses 32 threads on my 16 core CPU. But one of the messages before claims that it doesn't use SMT (so tries to restrict to actual cores in some way or number). It reports number of cores and threads in the system, but it doesn't report how many threads will be actually used during execution. schedtool `ps --no-headers -C xlinpack_amd64 -L -o lwp` shows same affinity for all threads and it is not restricting any thread or groups to specific cores, hyperthreads, it reads AFFINITY 0xffffffff for all threads. (Update: I was observing top and for a moment I have seen it using 16 cores (every second "cpu"/hyperthread) without me touching anything, with GFlops actually increasing. I restarted it and it is doing 32 threads again. Strange!); (Update2: I believe part of each pass is using 32 threads, and the other is using 16 threads. The phase that is using 16 threads is somewhere in the middle of each pass, and lasts about 10% of entire run time of each pass. My guess phases are data generation, decomposition?, forward propagation, back propagation, solution verification, and they use different number of threads?).
  • If computations are done in double precission, outputing residuals to only 7 significant digits is not enough, 15-16 should be used. It is enough for single precision work tho.
  • GFlops column shows results with 4 decimal digits after decimal point (i.e. for a total of 7 significant digits), both for individual passes and for averages. That is wrong, and simply a bad statistical practice, considering time is only show to milisecond (for a total of 4-5 significant digits).
  • Would be nice for "Maximum memory request" to print size using human friendly units, i.e. used=1613408096 bytes (1538.7 MiB)
  • I would remove runme_* files completely. They are semi useless, and most people know how to redirect output to file. They setup of number of threads should be moved to main code, and set via settings file, or command line arguments, and default should be computed in main code automatically. It is trivial to find number of CPUs using getconf(_NPROCESSORS_ONLN) for example, or sched_getaffinity(...).
  • It is GFLOPS or Gflops, GFLOPs/s, not GFlops.
  • Residual - is it a absolute-max (L0), absolute-sum (L1), sum? Residual(norm) - is it L1 or L2 norm?
Just initial thoughts.

I find prime95 stressing my system much better, it runs continually and makes my system reach steady state (temperature and frequencies on cores) in few minutes. It also reduces amount of inter thread communication to minimum, to really push CPU core to maximum, and not focus so much on cache, coherency or memory subsystem too much. While running LinpackXtreme I see 20 runs (for Size 14200 I actually run 40 runs, and for Size 31700 I run 30 runs), it shows my core frequencies are much higher than when running prime95, meaning LinpackXtreme doesn't actually stresses cores thermally enough. I can provide graphs.
 
Last edited:
Version 0.9.6 released to address core count detection of MP/DP systems on Windows.
 
Regeneration said:
Version 0.9.6 released to address core count detection of MP/DP systems on Windows.
Click to expand...

OP links dont go to 0.9.6

So, a few things

1. Corsairs iCue software is a CPU hog to the max
2. my waterblock wasnt correctly mounted for a long time...

capture141.jpg
 
Prime95 just crashed my system (x101 bsod) after it passed 100 passes of Linpack Xtreme at 2GB and 6GB... granted I didn't use the bootable Linux test, but I thought it was worth mentioning.

I am trying the Linux version now real quick before run prime95 again, after making some adjustments. I'm super nooby at Linux, but I at least can mange to follow simple instructions...
 
Last edited:
I believe I was running 0.9.6... I would have just downloaded it yesterday.

Anyway just passed in the bootable Linux version with default settings (20 passes at 4GB I believe) so moving on to prime95 again.

-ed I see we're up to version 1.0 for Windows. Gave that a quick run, 20 passes at 2GB and no error. Moving on to prime95 now. Hopefully no errors or crash this time...
 
Last edited:
only detects two threads for my G4560 :(
 
Awesome program, terrifying temp spikes...:toast:
 
Well, this program opened a VTRoot folder in my root drive, then made few subofolders and a "ytemp" folder, then tried to use attrib +h command to hide the file inside. It also made folders in temporary files and in my user folder. After that my cpu went to 100%, but each time I opened task manager, it would drop to 3%. Also, my cpu fan started making weird noises. Are you sure your program wasn't injected with a cryptominer or something? And then, the 64 bit version wouldn't start and said something about bad memory.
 
Doesn't have any form of network connectivity. And definitely doesn't send a radio signal to the B29 sector in the north side of the galaxy.

The CPU usage monitor in Windows 10 task manager is somehow broken. Only the 'details' tab shows the real usage for all processes.

CPU running stress tests normally overheat and the motherboard increases the CPU fan speed to compensate. This is why your CPU fan making weird noises.
 
You must log in or register to reply here.
Back
Top