Developer Guide

  • 2021.2
  • 06/11/2021
  • Public
Contents

Step 2: Run MRL on Untuned System

In this step, you will run the MRL workload validation script on the untuned system that you set up in Step 1: MRL Setup. As described in the scenario, Intel® TCC Mode is enabled in BIOS. This step will produce a baseline latency measurement of how the system performs with Intel® TCC Mode enabled, which you will later compare with the latency measurement gathered after tuning the system with the data streams optimizer.
The output examples shown here are for illustration only. Your output may vary.
To run MRL on an untuned system:
  1. From your host system, connect to the target board via SSH if it is not already connected. Replace
    <user>
    with the username (typically it is
    root
    for customer reference boards). Replace
    <target>
    with the IP address or hostname of the target board.
    ssh <user>@<target>
  2. In the SSH session
    , make sure that Intel® TCC Tools are installed on the target board:
    ls /usr/share/tcc_tools/ -la
    If the directory is empty, Intel® TCC Tools are not installed. Complete the installation instructions in the Get Started Guide.
  3. [Target board]
    Get the PCI device name:
    The MRL workload validation script supports integrated TSN Ethernet controllers and Intel® Ethernet Controller I225 devices. To check which device you have, run:
    lspci | grep -E 'Ethernet controller: Intel Corporation'
    Output example:
    aa:00.0 Ethernet controller: Intel Corporation Device 15f2 (rev 03)
    If you see
    15f2
    in the output, the device is an Intel® Ethernet Controller I225. If you see
    a0ac
    or
    4b32
    in the output, the device is an integrated TSN Ethernet controller.
  4. [Target board]
    Run the workload validation script, using the following command. Replace
    <device_name>
    in the
    --device
    argument. For example,
    I225
    or
    TSN
    . Make sure to delete the angle brackets (< >) too.
    python3 /usr/share/tcc_tools/tools/demo/workloads/bin/mrl_validation_script.py --latency_us 90 --device <device_name> --iterations 10000000 --core 3
  5. Leave the rest of the arguments as is. For reference, the following table describes the arguments:
    Argument
    Description
    --latency_us 90
    Required. Maximum latency requirement in microseconds (us) to be verified.
    --iterations 10000000
    Optional. Number of iterations.
    --core 3
    Optional. Processor core on which the sample will run.
  6. Note that in the workload validation script command,
    --latency_us
    is the maximum latency requirement for MRL latency. It is set to 90 microseconds, which aligns to the scenario. If the actual latency exceeds this requirement, the validation is considered a fail.
    The workload validation script is an example of how the sample can be used in the data streams optimizer workflow. To prepare a validation script for your workload, see Create a Workload Validation Script.
  7. Confirm that you see output similar to the example below.
    Enabling userspace access to performance counters Removing igc Start validation Running test ... Done. Test is complete! Results saved in data_mmio_read_latency_us.csv data_mmio_read_latency_ticks.csv data_avg_inst_count.csv Validation stopped Restoring igc Validation is finished. Please wait for results processing. Validation information: device: I225 address: 0x88200000 core: 3 iterations: 10000000 processor: TGL-U Latency must be less than 90.0 us. Statistics: |Min |Max |Avg |Median ---------------------------------------------------------------- Microseconds |1.216 |12.733 |1.559 |1.545 ================================================================ Deadline |Iterations |Passed |Failed --------------------------------------------------- 100.0 us |10000000 |10000000 |0 =================================================== Success: all iterations passed.
    The first table displays:
    • Min: Minimum latency (execution time of the fastest iteration)
    • Max: Maximum latency (execution time of the slowest iteration)
    • Avg: Average latency
    • Median: Median latency
    The second table displays:
    • Deadline: Maximum tolerable latency for each iteration
    • Iterations: Total number of iterations
    • Passed: Number of iterations that met the deadline
    • Failed: Number of iterations that exceeded the deadline
    The script compares the maximum latency measurement to the deadline. In this example, the maximum latency measurement of 12.733 µs is lower than the requirement of 90.0 µs, and the validation is considered a success. By observing the number of failed and passed iterations, you can understand how critical the maximum latency measurement is for your deadline. The values may be different on your system.
    Although the Intel® TCC Mode settings in BIOS already meet the latency requirement, they may not be optimal for other requirements. For example, Intel® TCC Mode disables all power management settings and may negatively affect use cases that have power consumption requirements. The data streams optimizer can balance latency and power requirements.
    The following diagram depicts the information in the output results: The untuned state of Intel® TCC Mode in which latency is low and power consumption is unlimited.
  8. Make a note of the maximum latency measurement so you can compare it to the measurement that you will get after tuning the system.
  9. Exit the connection to the target board.
    exit

Product and Performance Information

1

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.