Whats a good way to stress test the processor on my pi 4? Looking to test the cpu fan

[rasput1n]

I have a PoE hat and I suspect the fan isn't turning on as it should. Whats a good way to make the cpu run hot so the fan should kick on?

Thanks,
Matt

[aBUGSworstnightmare]

https://www.jeffgeerling.com/blog/2020/ ... w-case-fan

[jahboater]

Try cpuburn:

Code: Select all

wget https://raw.githubusercontent.com/ssvb/cpuburn-arm/master/cpuburn-a53.S
gcc -o cpuburn-a53 cpuburn-a53.S
./cpuburn-a53

This downloads, assembles, and runs cpuburn. For future runs, just do the last line.
This stress test does some NEON stuff on all four cores and (on 32-bit Raspberry Pi OS) will raise the temperature quickly.

To display the temperature:

Code: Select all

vcgencmd measure_temp

and:

Code: Select all

vcgencmd get_throttled

to see if the Pi4 has throttled back (reached 80C at some point) - it should always say 0x0

[rasput1n]

Worked great, thanks!

[DarkElvenAngel]

I normally use

Code: Select all

yes &>/dev/null &
yes &>/dev/null &
yes &>/dev/null &
yes &>/dev/null &

that drives the CPU at 100%

then I can

Code: Select all

killall yes

when I'm finished, so is cpuburn better or does it really matter? In the end the CPU is at 100% either way?

Just interested, thanks

[jahboater]

I normally use

Code: Select all

yes &>/dev/null &
yes &>/dev/null &
yes &>/dev/null &
yes &>/dev/null &

that drives the CPU at 100%

then I can

Code: Select all

killall yes

when I'm finished, so is cpuburn better or does it really matter? In the end the CPU is at 100% either way?

I sometimes do

Code: Select all

yes >/dev/null & yes >/dev/null & yes >/dev/null & yes >/dev/null &

which is similar.
"yes" is a simple integer load that's easy for the Pi CPU's to execute.

Cpuburn spawns processes to run on all four cores, all of which are automatically stopped when you type Control-C.

Cpuburn does some stuff with NEON which seems to raise the temperature very quickly.
NEON is quad issue so in theory it is doing four operations per cycle (on all four CPU cores of course).
Also NEON is SIMD so it is working with 128-bit registers.

On the first Pi3, cpuburn would crash the system in a few seconds.
As time goes on, Pi's have handled it better, and now with the Pi4, if there is a good heat sink, it may not even reach throttling.

cpuburn seems to run hotter in 32-bit mode.

[DarkElvenAngel]

Cpuburn sounds a little like a fork bomb for older Pi's. I'm going to have to do a test with both and see now how they compare. I appreciate your response.

Thanks.

[emma1997]

Thanks to DEA for that yes trick.

Built-in functions are very important to me for a variety of reasons. Having to hunt down or, worse still, compile from scratch not so much. I have no idea what's going on but works like a charm cooking these puppies to the max.

[jahboater]

Built-in functions are very important to me for a variety of reasons. Having to hunt down or, worse still, compile from scratch not so much. I have no idea what's going on but works like a charm cooking these puppies to the max.

Try typing "yes" alone on the command line, you will see how it works!

[Milliways]

The repository has a stress package.

There is a python utility stressberry which uses this and performs comprehensive tests and plots graph of performance & temperature.

[emma1997]

Try typing "yes" alone on the command line, you will see how it works!

yyyyyyyyyyyyyyyyyyyyyyyyyyyikes!!! lol

Also explains what the NUL is for. Amazing something that simple can clog up CPUs like that. And now I've also learned how to trick other cores into action. And thanks for the ^C tip.

I recall writing a similar utility long time ago for MSDOS to 'force' positive replies. Deja Vu all over again.

[ejolson]

Try typing "yes" alone on the command line, you will see how it works!

yyyyyyyyyyyyyyyyyyyyyyyyyyyikes!!! lol

Also explains what the NUL is for. Amazing something that simple can clog up CPUs like that. And now I've also learned how to trick other cores into action. And thanks for the ^C tip.

I recall writing a similar utility long time ago for MSDOS to 'force' positive replies. Deja Vu all over again.

If cpuburn is working as expected, the amount of heat generated and electricity consumed should be much greater than four copies of yes piped into null. It's true however that GNU yes and Linux pipes have been optimised in crazy ways, so maybe it's still a good stress test. I've got a USB power meter on the shelf that I've been meaning to try out for some time.

Even if differences in power consumed don't directly correspond to heat, they might at least be interesting to report.

[emma1997]

I would also be interested in the difference. IIRC somebody mentioned earlier cpuburn heats faster but it would be nice to quantify that. 2x? 10x?

I'd do it myself but unfortunately don't have internet or disk space to spare which is why I like this yes thing in the first place. I suppose a Pi loaded up with cooling fins or liquid nitrogen might show more difference but I don't have either of those either.

[DarkElvenAngel]

I would also be interested in the difference. IIRC somebody mentioned earlier cpuburn heats faster but it would be nice to quantify that. 2x? 10x?

I'd do it myself but unfortunately don't have internet or disk space to spare which is why I like this yes thing in the first place. I suppose a Pi loaded up with cooling fins or liquid nitrogen might show more difference but I don't have either of those either.

I'm planning to do these test I just don't have time till the end of the week. I want to see the differences between the two options. As I use yes for my tests I'd like to see if there is a noticeable difference.

[jahboater]

I would also be interested in the difference. IIRC somebody mentioned earlier cpuburn heats faster but it would be nice to quantify that. 2x? 10x?

I'd do it myself but unfortunately don't have internet or disk space to spare which is why I like this yes thing in the first place. I suppose a Pi loaded up with cooling fins or liquid nitrogen might show more difference but I don't have either of those either.

This is the source code it is very small:

Code: Select all

/*
 * Copyright © 2016 Siarhei Siamashka <siarhei.siamashka@gmail.com>
 *
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and associated documentation files (the "Software"),
 * to deal in the Software without restriction, including without limitation
 * the rights to use, copy, modify, merge, publish, distribute, sublicense,
 * and/or sell copies of the Software, and to permit persons to whom the
 * Software is furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice (including the next
 * paragraph) shall be included in all copies or substantial portions of the
 * Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
 * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 * DEALINGS IN THE SOFTWARE.
 */

/*
 * This program tries to stress ARM Cortex-A53 processor to generate as
 * much heat as possible.
 * WARNING: improperly cooled or otherwise flawed hardware may potentially
 * overheat and fail. Use at your own risk.
 *
 * Compilation instructions:
 *     $ aarch64-linux-gnu-gcc -o cpuburn-a53 cpuburn-a53.S
 * or
 *     $ arm-linux-gnueabihf-gcc -o cpuburn-a53 cpuburn-a53.S
 *
 * See http://ssvb.github.io/2012/04/10/cpuburn-arm-cortex-a9.html
 * for more details.
 */

#define LOOP_UNROLL_FACTOR   100

#ifdef __aarch64__

/****************************************************************************/
/* 64-bit implementation                                                    */
/****************************************************************************/

    .cpu cortex-a53+fp+simd
    .text
    .align 2
    .global main
    .type main, %function

main:
        stp         x29, x30, [sp, #-16]!

#ifdef __linux__
        mov         w0, #84 /* _SC_NPROCESSORS_ONLN */
        bl          sysconf
        mov         w29, w0
        cmp         w29, #2
        blt         1f
        bl          fork /* have at least 2 cores */
        cmp         w29, #4
        blt         1f
        bl          fork /* have at least 4 cores */
        cmp         w29, #8
        blt         1f
        bl          fork /* have at least 8 cores */
1:
#endif

        movi        v28.16b, #0xff
        movi        v29.16b, #0xff
        movi        v30.16b, #0xff
        movi        v31.16b, #0xff

        adr         x4, 9f
        add         x4, x4, #1
        mov         x1, #0
        mov         x2, #(64 / 4)

        b           0f

    .ltorg
9:
    .rept 64
        .long 0xffffffff
    .endr

    .balign 64
0:
    .rept LOOP_UNROLL_FACTOR
        uaba        v8.4s, v28.4s, v29.4s
        bne         1f
1:      uaba        v9.4s, v30.4s, v31.4s
        ldr         w0, [x4, x1, lsl #2]
        uaba        v10.4s, v28.4s, v29.4s
        bne         1f
1:      uaba        v11.4s, v30.4s, v31.4s
        ldr         w0, [x4, x2, lsl #2]
    .endr
        b           0b

        mov         w0, #0
        ldp         x29, x30, [sp], #16
        ret

/****************************************************************************/

#else

/****************************************************************************/
/* 32-bit implementation                                                    */
/****************************************************************************/

    .syntax unified
    .text
    .arch armv7-a
    .fpu neon
    .global main
    .type main, %function
    .align 2
    .arm

main:
        push        {r4-r12, lr}

#ifdef __linux__
        mov         r0, 84 /* _SC_NPROCESSORS_ONLN */
        bl          sysconf
        mov         r4, r0
        cmp         r4, #2
        blt         1f
        bl          fork /* have at least 2 cores */
        cmp         r4, #4
        blt         1f
        bl          fork /* have at least 4 cores */
        cmp         r4, #8
        blt         1f
        bl          fork /* have at least 8 cores */
1:
#endif

        vmov.u8     q12, #0xff
        vmov.u8     q13, #0xff
        vmov.u8     q14, #0xff
        vmov.u8     q15, #0xff

        adr         lr, 9f
        add         lr, lr, #1
        mov         r1, #(64 / 4)
        mov         r2, #(-64 / 4)

        b           0f

    .ltorg
9:
    .rept 64
        .long 0xffffffff
    .endr

    .balign 64
0:
    .rept LOOP_UNROLL_FACTOR
        vaba.u32    q8, q12, q13
        bne         1f
1:      vaba.u32    q9, q14, q15
        ldrne       r0, [lr, r1, lsl #2]!
        vaba.u32    q10, q12, q13
        bne         1f
1:      vaba.u32    q11, q14, q15
        ldrne       r0, [lr, r2, lsl #2]!
    .endr
        b           0b

        mov         r0, #0
        pop         {r4-r12, pc}

/****************************************************************************/

#endif

[jahboater]

If cpuburn is working as expected, the amount of heat generated and electricity consumed should be much greater than four copies of yes piped into null. It's true however that GNU yes and Linux pipes have been optimised in crazy ways, so maybe it's still a good stress test.

"yes >/dev/null" is simply writing to the null device, it is not a pipe. File descriptor 1 is reopened for "/dev/null" by the shell before it starts yes.
Yes doesn't know any different.
This looks like a pipeline, but each & starts the previous command in the background:-

Code: Select all

yes >/dev/null & yes >/dev/null & yes >/dev/null & yes >/dev/null &

cpuburn exercises NEON which is a) complex and b) quad issue.
So I suspect its doing (at least) 16 operations per clock cycle.

Another large part of the SoC real estate is the GPU. I sure someone could write code to exercise that!

[emma1997]

This is the source code it is very small:

Probably not the case here but what I've learned is source code is not always a good indicator of disk usage at all. I won a bet once by proving a 20 byte source file ended up taking 4gig disk space while a 1meg one compiled to only 5 bytes.

In my case it's also a matter of time needed to install and maintain these gadgets. With around 20 setups now between work and home, better to keep them as close to original image as possible. That and my tendency to start from scratch on every new release means the fewer extra steps and less fuss the better. Takes less than 15min now and don't want that to grow out of control.

Built-in functions will always take precedence over things that need installing or specially if needs compiling too. Over the years KISS policy has proven the key to managing all my OS stuff, Winders or Linucks.

[ejolson]

This is the source code it is very small:

Probably not the case here but what I've learned is source code is not always a good indicator of disk usage at all.

The cpuburn-a53 source code is 5K, compiles to 12K that when stripped is 10K.

Code: Select all

$ ls -l
total 8
-rw-r--r-- 1 ejolson users 5129 Mar  3 21:25 cpuburn-a53.S
$ gcc -o cpuburn-a53 cpuburn-a53.S
$ ls -l
total 20
-rwxr-xr-x 1 ejolson users 12128 Mar  3 21:28 cpuburn-a53
-rw-r--r-- 1 ejolson users  5129 Mar  3 21:25 cpuburn-a53.S
$ strip cpuburn-a53
$ ls -l
total 20
-rwxr-xr-x 1 ejolson users 9648 Mar  3 21:28 cpuburn-a53
-rw-r--r-- 1 ejolson users 5129 Mar  3 21:25 cpuburn-a53.S

Now I have to connect the fan so no throttling occurs while measuring the amount of power which is consumed.

[ejolson]

Now I have to connect the fan so no throttling occurs while measuring the amount of power which is consumed.

Here are my measurements:

Code: Select all

Test                  Amperes
idle               0.45 to 0.50
cpuburn-a53        1.01 to 1.06
yes >/dev/null     0.83 to 0.88

It would appear cpuburn about 21 percent more electricity and might generate about that much more heat. I did not perform a longtime study to see how well my fan setup worked, but there was no throttling.

For reference my Pi pie chart program

viewtopic.php?t=227177

in stress mode obtains

Code: Select all

Test                  Amperes
Prime Sieve        0.97 to 1.04
Merge Sort         0.89 to 1.01
Fourier            0.72 to 0.85
Lorenz 96          1.24 to 1.30

I find it curious that Lorenz 96 manages to consume 23 percent more power than cpuburn-a53. Likely that a53-optimized assembler is far from ideal for the cortex-a72 cores used on the Raspberry Pi 4B. Given the reported number of floating-point operations per second, I suspect the high-performance Linpack benchmark would be a better stress test than any of the above.

viewtopic.php?t=276089

[jahboater]

How does stress-ng perform?

Code: Select all

sudo apt install stress-ng

Code: Select all

stress-ng --cpu 4 --cpu-method fft 

This seems to raise the temperature much higher than cpuburn on my 64-bit Pi4.

[ejolson]

How does stress-ng perform?

Code: Select all

sudo apt install stress-ng

Code: Select all

stress-ng --cpu 4 --cpu-method fft 

This seems to raise the temperature much higher than cpuburn on my 64-bit Pi4.

The results for stress-ng is

Code: Select all

Test                  Amperes
stress-ng fft      1.12 to 1.17

As with other packages in the 32-bit version of Raspberry Pi OS, stress-ng was likely compiled to be reverse compatible with ARMv6 models. This means the same test running on the 64-bit operating system may consume more power.

[DarkElvenAngel]

Thanks for the testing results very interesting.

[jahboater]

As with other packages in the 32-bit version of Raspberry Pi OS, stress-ng was likely compiled to be reverse compatible with ARMv6 models. This means the same test running on the 64-bit operating system may consume more power.

Thanks for these interesting results.
Looks like Lorenz 96 followed by stress-ng fft are the two best stress tests.