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

SLE RT Hardware Testing

SUSE Linux Enterprise Real Time 12 SP5

Publication Date: 11/14/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, we describe 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

    The histogram file can be visualized with the cyclictest_plot.sh script. The result is a PNG file.

3 Determining Latencies with the Hardware Latency Detector

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

The hardware latency detector module works by making all CPUs busy for a 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 System Management Interrupts (SMI).

To start using hardware latency detector, use as root:

modprobe hwlat_detector enabled=1 threshold=10

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

After the module is loaded, the /sys/kernel/debug/hwlat_detector/ directory is created. The directory contains several files:

count

Contains the number of latency spikes (larger than threshold) observed since the last reset.

enable

The global enable/disable toggle (0/1), resets the count.

max

The maximum hardware latency that has been observed, in microseconds.

sample

A pipe from which to read current raw sample data in the format timestamp observed latency in microseconds (can be opened with parameter O_NONBLOCK for a single sample).

threshold

The minimum latency value to be considered, in microseconds.

width

The time period to sample with CPUs held, in microseconds. Must be less than the total window size (enforced).

window

The total size of the sampling window (including the width), in microseconds.

After running the hardware latency detector for a significant amount of time, check the values of count and max. For a detailed analysis, you can use the output from sample.

4 For 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 http://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.