Jump to content
documentation.suse.com / SLE RT Hardware Testing
SUSE Linux Enterprise Real Time 15 SP6

SLE RT Hardware Testing

Publication Date: 12/12/2024

Using SUSE® Linux Enterprise Real Time needs real-time capable hardware. This paper describes the tools that can be used to determine if a specific hardware has the needed real-time capabilities. Specifically, it describes cyclictest and hardware latency detector and the ways to analyze their results.

Both the cyclictest and the hardware latency detector are parts of the SUSE Linux Enterprise Real Time product.

1 General testing procedure and analysis

The first task you need to do when evaluating hardware for real-time is described in the following procedure:

  1. Determine the largest allowable latency of the system using the hardware latency detector:

    1. Set the machine for real-time performance.

      Some servers have special settings for real-time, but they are strictly vendor specific.

    2. Set everything to lowest possible latency.

    3. Turn memory scrubbing down to as little as possible.

    4. Use the hardware latency detector (see Section 3, “Determining latencies with the hardware latency detector” for details).

  2. Check the latencies measured by the hardware latency detector.

    The latencies should be low enough to support your real-time application with enough of a margin to meet its deadlines. If it is not the case, even after tweaking the machine setting for better real-time performance, the hardware is not good enough for your application. Use a different hardware.

  3. Measure latencies using cyclictest (see Section 2, “Determining latencies with cyclictest for details).

    In a typical situation the latencies measured with cyclictest should be mostly the same from those measured by the hardware latency detector. Latencies measured by cyclictest include the latencies caused by the operating system and are thus closer to latencies measured in a real computing situation.

If you encounter a significant difference between latencies measured by both methods there might be a software bug involved. Such latencies are a significant part caused by the operating system, not the hardware. In such a case, contact SUSE for support.

2 Determining latencies with cyclictest

The cyclictest command is part of the real-time kernel test suite contained in the rt-tests RPM package. This package is distributed as part of SUSE Linux Enterprise Real Time.

Make sure to be root or use sudo to run cyclictest.

When cyclictest is running, it shows the number of cycles performed and the minimal, actual, average and maximum latency measured. To change the behaviour of cyclictest, the following list gives you an overview of the available options:

  • The values shown are in microseconds. To use nanoseconds instead of microseconds, use the --nsec option.

  • By default, cyclictest runs forever. The number of cycles can be limited with the --loops=NUMBER_OF_CYCLES option.

  • By default, only one thread is run. You can use the --threads=NUMBER_OF_THREADS option to set the number of threads used. Without specifying a number, all available processors are used. With the --affinity option, the threads are pinned to the processors with the same number.

  • To create a histogram with the latency values, use the --histogram=NUMBER_OF_MICROSECONDS option, where NUMBER_OF_MICROSECONDS determines the maximum tracking time. Larger values are reported as histogram overflows. The histogram is written to standard out (STDOUT), but you can redirect it to a file:

    cyclictest --loops=1000 \
    --histogram=1000 > histogram

3 Determining latencies with the hardware latency detector

The hardware latency detector (hwlatdetect) is a program that controls the kernel latency detector module (hwlat_detector.ko), installed with the real-time debug kernel (the kernel-rt_debug package). This is a special kernel module that is used to detect large system latencies, caused by the behavior of the underlying hardware or firmware, independent of Linux itself (system management interrupts, SMIs).

The hardware latency detector module works by making all CPUs busy for configurable amounts of time. This is done by calling stop_machine(), polling the CPU Time Stamp Counter (TSC) for some period, and then looking for gaps in the TSC data. These gaps indicate times when the polling was disturbed by SMIs.

To start using hardware latency detector, use as root:

hwlatdetect --threshold=10

The threshold value is the minimum latency value to be considered in microseconds. Use the value which is relevant for your particular situation.

hwlatdetect has the following options:

--duration="VALUE"{s,m,h,d,w}

Run the detector logic for the specified duration. Provide the duration as a decimal integer value. The default duration unit for this value is seconds. To use a different unit, append m (minutes), h (hours), d (days), or w (weeks) to the value.

--threshold="VALUE"{us,ms,s}

Specify the TSC gap used to detect an SMI. Any gap value greater than threshold value is considered to be the result of an SMI occurring. The default duration unit for this value is microseconds. To use a different unit, append ms (milliseconds) or s (seconds) to the value.

--hardlimit="VALUE"{us,ms,s}

The test is considered to have failed if a value above the hard limit value occurs. The default duration unit for this value is microseconds. To use a different unit, append ms (milliseconds) or s (seconds) to the value.

--window="VALUE"{us,ms,s}

Specify the size of the sample window. The default duration unit for this value is microseconds. To use a different unit, append ms (milliseconds) or s (seconds) to the value.

--width="VALUE"{us,ms,s}

The amount of time within the sample window where the detector is actually sampling. Must be less than the --window value. The default duration unit for this value is microseconds. To use a different unit, append ms (milliseconds) or s (seconds) to the value.

--report=FILE_NAME

Specify the output file name of the detector report. The default behavior is to print to standard output.

--debug

Turn on debug output

--quiet

Turn off information output.

--watch

Print sample data to stdout as it arrives.

4 More information

For more information on cyclictest, see man 8 cyclictest.

For more information on the hardware latency detector, see /usr/src/linux/Documentation/hwlat_detector.txt.

5 Legal notice

Copyright© 2006–2024 SUSE LLC and contributors. All rights reserved.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled GNU Free Documentation License.

For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.