Stress testing

A good stability test of a low load workload is to run though updating the patch sets in the OpenWRT project. Follow these steps.

git clone --depth 1 git@github.com:openwrt/openwrt.git
cd openwrt
mkdir -p staging_dir/host/bin
cp /usr/bin/sed ./staging_dir/host/bin
curl -Os https://raw.githubusercontent.com/KanjiMonster/maintainer-tools/master/update_kernel.sh
chmod +x update_kernel.sh
./update_kernel.sh -v -u 5.4

performs a loop that calculates the square root of a random number in order to stress the CPU. It can run simultaneously several workers to load all the cores of a CPU for example. It can also generate memory, I/O or disk workload depending on the parameters passed. The FAQ provides examples and explanations.

To spawn 4 workers working on calculating a square root, use the command:

$ stress --cpu 4

is a lightweight stress-testing program written by CodeLog that stimulates the processor by computing the Ackermann function.

MPrime (also known as Prime95 in its Windows and MacOS implementation) is recognised universally as one defacto measure of system stability. MPrime under torture test mode will perform a series of very CPU intensive calculations and compare the values it gets to known good values.

The Linux implementation is called .

To run mprime, simply open a shell and type "mprime":

$ mprime

When the software loads, simply answer 'N' to the first question to begin the torture testing:

There are several options for the torture test (menu option 15).

• Small FFTs (option 1) to stress the CPU
• In-place large FFTs (option 2) to test the CPU and memory controller
• Blend (option 3) is the default and constitutes a hybrid mode which stresses the CPU and RAM.

Errors will be reported should they occur both to stdout and to ~/results.txt for review later. Many do not consider a system as 'stable' unless it can run the Large FFTs for a 24 hour period.

Example ~/results.txt; note that the two runs from 26-June indicate a hardware failure. In this case, due to insufficient vcore to the CPU:

linpack^AUR makes use of the BLAS (Basic Linear Algebra Subprograms) libraries for performing basic vector and matrix operations. It is an excellent way to stress CPUs for stability (only Intel CPUs are supported). After installation, users should copy to and adjust it according to the amount of memory on the system.

(aka SuperPi for Windows) is available in both CLI and GUI version. It tests system stability by calculating up to 128 millions of Pi digits and includes error checking. Note that one can select from two different calculation algorithms: Quadratic Convergence of Borwein and Gauss-Legendre. The latter being the same method that the popular SuperPi for Windows uses.

A CLI example using 8 threads is given:

$ systester-cli -gausslg 64M -threads 8

The Intel Processor Diagnostic Tool is a tool that verifies the functionality of an Intel Microprocessor by stress testing the CPU. A Fedora Linux LiveUSB ISO images are available. The LiveUSB image allows you to stress test your machine without using your main operating system; such method might be useful in extreme cases especially when dealing with cold reboots/crashes.

Burn the image to a USB stick by using dd or Gnome Disks and then boot the Live CD. Once booted, open the terminal and type the following command to install Intel Processor Diagnostic Tool for 64-bit machines:

$ install64

Once it is installed, you can run the Diagnostic Tool by clicking on the IPDT Icon that is located on the desktop.

Use MemTest86 (proprietary) or Memtest86+ (GPL) to test your memory (RAM). There are "new" and "old" testers:

• "New" versions do not support BIOS. For a new version, use a proprietary MemTest86 version greater or equal to 8. Install it as or boot the Arch Linux install image.
• "Old" versions do not support UEFI nor DDR4. Old versions are available as GPL (development discontinued). It is roughly equal to proprietary MemTest86 version 4. After installation, update GRUB: it will auto-detect the package and allow users to boot directly to it.

A good stability test under a low load workload is using dd to format an image. This can be a physical disk or a loop mounted image. The script below uses mounted image and cycles through each core one-by-one. Note that you should adjust the variables in the top of script to match your system. By default the script will run the command just once per core. It can be easily customised to run on known-weak cores rather than scanning all core 0 through n by altering the for loop. Run the script as root.

Parallel compilation using GCC (or other compilers) will generate a heavy load on the CPU and memory. To avoid I/O bottlenecking, compile on a SSD or in a tmpfs.

The example below will compile the Linux kernel.

pacman -Syu asp
asp export linux
cd linux
makepkg -sf MAKEFLAGS="-j$(nproc)"

Most video encoders are highly parallel and are designed to use most of a CPU's capabilities. The example below will encode noise using x265, and discard the result. This will heavily load the CPU.

ffmpeg -y -f rawvideo -video_size 1920x1080 -pixel_format yuv420p -framerate 60 -i /dev/urandom -c:v libx265 -preset placebo -f matroska /dev/null