• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

New Linpack Stress Test Released

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
v0.9.2
- Added several optimizations for AMD CPUs.
- Improved multithreading efficiency for the benchmark.
- Fixed insufficient memory error on 32-bit systems.
- Updated CPUID HWMonitor to version 1.36.
- Some minor changes.
 
I may do some testing when I have time. Thanks for providing this interesting new tool. At first blush the flops (and CPU usage) seem low on my Ryzen 5 1600, but I'll have to use it more and pit it against some Intel stuff to get comparative results.
 
A new version is now available.

Both AMD and Intel users should get better scores when benchmarking since Linpack now runs only on real cores.

Threads will now spawn in a more balanced manner when stress testing. Most useful for non-Intel CPUs and MP/DP systems.
 
is there a way of specifying the # of threads prior to the run? On my quad-opteron (48 core) this thing only spawns 12 threads during the benchmark.
 
This is the "problem" with MP/DP rigs running Windows. A lot of apps and games use only one CPU because Windows categorizes each CPU separately.
 
Interesting, i rebooted and in my SuperMicro BIOS set things to node interleaving On. (ie non NUMA mode - evens out memory latency to all sockets). - 187 GFlops.

With the BIOS set to NUMA mode (ie node interleaving Off)... results were - 148.xx GFlops.

i normally have it set to NUMA for exactly the reasons you mention. i like to have most games sit on socket 1 and use the memory attached to that socket... better latency = higher fps.

Linpack seems to like more memory bandwidth however.

This is with 4 Opteron 61xx series (12 K10 cores each) running at 3.0 GHz. Unfortunately i can't try running at 3.3 since these 92mm Noctuas won't cool fast enough 🙁

Regeneration said:
This is the "problem" with MP/DP rigs running Windows. A lot of apps and games use only one CPU because Windows categorizes each CPU separately.
Click to expand...
 
Ran the benchmark to see what I'd get. Only 228 GFlops. Running the stress test with 8 threads and 9.6GB allocated yields this.
AUk1n0d.png
 
Regeneration said:
The benchmark results are comparable with other people. Ryzen 2700X is getting around 180 GFlops.
Click to expand...
I would be interested to see someone with an i7 8700k's Linpack Extreme results overclocked. I routinely ran LinX 0.6.5 (Linpack with AVX2 front end) at 5 GHz, but I did not keep track of the Gflops (I was testing heatsinks). I wonder . . .
 
Its a bit strange. K10 is supposedly capable of 4 DP per cycle - "4 DP FLOPs/cycle: 2-wide SSE2 addition + 2-wide SSE2 multiplication". Yet i am getting nowhere near that.

i'm running 48 K10s at 3.0 GHz... my performance should be approximately 2.5 to 3x what it is (ie at least in the high 400s).

https://www.degruyter.com/downloadpdf/j/comp.2013.3.issue-1/s13537-013-0101-5/s13537-013-0101-5.pdf

tamz_msc said:
^That is exactly what I would expect. 86-87% efficiency, 8 DP ops/clock, 8 cores, 3.8 GHz. Multiply all of it together and it comes to ~210 GFLOP/s.
Click to expand...
 
Last edited:
rvborgh said:
Its a bit strange. K10 is supposedly capable of 4 DP per cycle - "4 DP FLOPs/cycle: 2-wide SSE2 addition + 2-wide SSE2 multiplication". Yet i am getting nowhere near that.

i'm running 48 K10s at 3.0 GHz... my performance should be approximately 2.5 to 3x what it is (ie at least in the high 400s).

https://www.degruyter.com/downloadpdf/j/comp.2013.3.issue-1/s13537-013-0101-5/s13537-013-0101-5.pdf
Click to expand...
Maybe it still needs optimization for older architectures, or this is still not optimized for OpenMP?
 
new version seems to stress things a bit more and produces marginally better result.

48 K10 cores at 3.0 GHz.

187 GFlops NUMA mode (node interleaving off) up from 148.

250 GFlops non NUMA mode (node interleaving on) up from 187
 
This consistently reports a hardware failure within 10-15 minutes on my 8700K when running with 12 threads, seemingly regardless of processor settings. An OC which will happily run the latest Prime95 all day long? Failed. Stock? Failed. An anemic 3GHz at a toasty 1.45 volts? Failed. At this point I figure it must be some sort of bug with the program's error detection.

This behavior disappears when running with the same number of threads as physical cores (6), at which point it seems to be stable at the same settings as the latest Prime95.
 
Excessi0n said:
This consistently reports a hardware failure within 10-15 minutes on my 8700K when running with 12 threads, seemingly regardless of processor settings. An OC which will happily run the latest Prime95 all day long? Failed. Stock? Failed. An anemic 3GHz at a toasty 1.45 volts? Failed. At this point I figure it must be some sort of bug with the program's error detection.

This behavior disappears when running with the same number of threads as physical cores (6), at which point it seems to be stable at the same settings as the latest Prime95.
Click to expand...
I don't know about this new Linpack, but LinX 0.6.5 runs a 12-threaded 8700K for 30min, with no sign of shutting down. I used to run this over and over at various OC's, up to 5 GHz.
 
Excessi0n said:
This consistently reports a hardware failure within 10-15 minutes on my 8700K when running with 12 threads, seemingly regardless of processor settings. An OC which will happily run the latest Prime95 all day long? Failed. Stock? Failed. An anemic 3GHz at a toasty 1.45 volts? Failed. At this point I figure it must be some sort of bug with the program's error detection.

This behavior disappears when running with the same number of threads as physical cores (6), at which point it seems to be stable at the same settings as the latest Prime95.
Click to expand...

Can you post a screenshot?
 
Excessi0n said:
This consistently reports a hardware failure within 10-15 minutes on my 8700K when running with 12 threads, seemingly regardless of processor settings. An OC which will happily run the latest Prime95 all day long? Failed. Stock? Failed. An anemic 3GHz at a toasty 1.45 volts? Failed. At this point I figure it must be some sort of bug with the program's error detection.

This behavior disappears when running with the same number of threads as physical cores (6), at which point it seems to be stable at the same settings as the latest Prime95.
Click to expand...

I can confirm the same behavior on my system.

I've been playing with reduced memory timings for my memory and used Prime95 with 24GB allocated over night for 8 hours and a few hours the night before. I then ran AIDA64 stress test for a few hours today while doing other things. Everything passed. I then decided to try this new "Linpack Xtreme" test again for good measure with all threads. Previously, I've been using 8 threads since that's normally how you would use a Linpack test. It failed quickly with 16 threads. After reading your post I decided to underclock everything and run the test again. It failed the same way. The test failed at 3.8GHz (with all cores utilized) and with the memory at only 2133 with very loose timings. It should pass any test.

ECh0Wgn.png


This utility seemed like a great thing at first. I'm going to have to stop using it and any future release even if there is a fix. There is now huge doubt about its functionality. A stability test should only fail when there is indeed a valid failure. It should not be producing a false positive for instability. I'd recommend others also not use it.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top