2.4.1. RT-linux Performance Guide

Read This First

All performance numbers provided in this document are gathered using following Evaluation Modules unless otherwise specified.

Name Description
AM64x EVM AM64x SR2.0 Evaluation Module rev C with ARM running at 1GHz, DDR data rate 1600 MT/S

Table: Evaluation Modules

About This Manual

This document provides performance data for each of the device drivers which are part of the Process SDK Linux package. This document should be used in conjunction with release notes and user guides provided with the Process SDK Linux package for information on specific issues present with drivers included in a particular release.

If You Need Assistance

For further information or to report any problems, contact http://e2e.ti.com/ or http://support.ti.com/

2.4.1.1. System Benchmarks

2.4.1.1.1. Dhrystone

Dhrystone is a core only benchmark that runs from warm L1 caches in all modern processors. It scales linearly with clock speed. For standard ARM cores the DMIPS/MHz score will be identical with the same compiler and flags.

Benchmarks am64xx-hsevm: perf
cpu_clock (MHz) 1000.00
dhrystone_per_mhz (DMIPS/MHz) 2.90
dhrystone_per_second (DhrystoneP) 5128205.00

Table: Dhrystone Benchmark


2.4.1.1.2. Whetstone

Benchmarks am64xx-hsevm: perf
whetstone (MIPS) 3333.30

Table: Whetstone Benchmark

2.4.1.1.3. Stress-ng and Cyclic Test

stress-ng (next-generation) will stress test a embedded platform in various selectable ways. It was designed to exercise various physical subsystems as well as the various operating system kernel interfaces. stress-ng can also measure test throughput rates; this can be useful to observe performance changes across different operating system or types of hardware.

Cyclictest is most commonly used for benchmarking RT systems. It is one of the most frequently used tools for evaluating the relative performance of real-time systems. Some performance tests which use Cyclictest are System benchmarking, Latency debugging with tracing and approximating application performance.

Test command for running stress-ng and cyclictest together

stress-ng -c 4 --cpu-method all &

cyclictest -m -Sp80 -i400 -h400 -q -D1h

Latencies am64xx-hsevm:per-core
Minimum (usec) 7,8
Average (usec) 12,13
Maximum (usec) 168,88

Table: Stress-ng and Cyclic Test

2.4.1.2. Ethernet

Ethernet performance benchmarks were measured using Netperf 2.7.1 https://hewlettpackard.github.io/netperf/doc/netperf.html Test procedures were modeled after those defined in RFC-2544: https://tools.ietf.org/html/rfc2544, where the DUT is the TI device and the “tester” used was a Linux PC. To produce consistent results, it is recommended to carry out performance tests in a private network and to avoid running NFS on the same interface used in the test. In these results, CPU utilization was captured as the total percentage used across all cores on the device, while running the performance test over one external interface.

UDP Throughput (0% loss) was measured by the procedure defined in RFC-2544 section 26.1: Throughput. In this scenario, netperf options burst_size (-b) and wait_time (-w) are used to limit bandwidth during different trials of the test, with the goal of finding the highest rate at which no loss is seen. For example, to limit bandwidth to 500Mbits/sec with 1472B datagram:

burst_size = <bandwidth (bits/sec)> / 8 (bits -> bytes) / <UDP datagram size> / 100 (seconds -> 10 ms)
burst_size = 500000000 / 8 / 1472 / 100 = 425

wait_time = 10 milliseconds (minimum supported by Linux PC used for testing)

UDP Throughput (possible loss) was measured by capturing throughput and packet loss statistics when running the netperf test with no bandwidth limit (remove -b/-w options).

In order to start a netperf client on one device, the other device must have netserver running. To start netserver:

netserver [-p <port_number>] [-4 (IPv4 addressing)] [-6 (IPv6 addressing)]

Running the following shell script from the DUT will trigger netperf clients to measure bidirectional TCP performance for 60 seconds and report CPU utilization. Parameter -k is used in client commands to summarize selected statistics on their own line and -j is used to gain additional timing measurements during the test.

#!/bin/bash
for i in 1
do
   netperf -H <tester ip> -j -c -l 60 -t TCP_STREAM --
      -k DIRECTION,THROUGHPUT,MEAN_LATENCY,LOCAL_CPU_UTIL,REMOTE_CPU_UTIL,LOCAL_BYTES_SENT,REMOTE_BYTES_RECVD,LOCAL_SEND_SIZE &

   netperf -H <tester ip> -j -c -l 60 -t TCP_MAERTS --
      -k DIRECTION,THROUGHPUT,MEAN_LATENCY,LOCAL_CPU_UTIL,REMOTE_CPU_UTIL,LOCAL_BYTES_SENT,REMOTE_BYTES_RECVD,LOCAL_SEND_SIZE &
done

Running the following commands will trigger netperf clients to measure UDP burst performance for 60 seconds at various burst/datagram sizes and report CPU utilization.

  • For UDP egress tests, run netperf client from DUT and start netserver on tester.
netperf -H <tester ip> -j -c -l 60 -t UDP_STREAM -b <burst_size> -w <wait_time> -- -m <UDP datagram size>
   -k DIRECTION,THROUGHPUT,MEAN_LATENCY,LOCAL_CPU_UTIL,REMOTE_CPU_UTIL,LOCAL_BYTES_SENT,REMOTE_BYTES_RECVD,LOCAL_SEND_SIZE
  • For UDP ingress tests, run netperf client from tester and start netserver on DUT.
netperf -H <DUT ip> -j -C -l 60 -t UDP_STREAM -b <burst_size> -w <wait_time> -- -m <UDP datagram size>
   -k DIRECTION,THROUGHPUT,MEAN_LATENCY,LOCAL_CPU_UTIL,REMOTE_CPU_UTIL,LOCAL_BYTES_SENT,REMOTE_BYTES_RECVD,LOCAL_SEND_SIZE

2.4.1.2.1. CPSW/CPSW2g/CPSW3g Ethernet Driver

TCP Bidirectional Throughput

Command Used am64xx-hsevm: THROUGHPUT (Mbits/sec) am64xx-hsevm: CPU Load % (LOCAL_CPU_UTIL)
netperf -H 192.168.0.1 -j -c -C -l 60 -t TCP_STREAM; netperf -H 192.168.0.1 -j -c -C -l 60 -t TCP_MAERTS 1096.39 75.79

Table: CPSW TCP Bidirectional Throughput


UDP Throughput

Frame Size(bytes) am64xx-hsevm: UDP Datagram Size(bytes) (LOCAL_SEND_SIZE) am64xx-hsevm: THROUGHPUT (Mbits/sec) am64xx-hsevm: Packets Per Second (kPPS) am64xx-hsevm: CPU Load % (LOCAL_CPU_UTIL)
64 18.00 11.26 78.00 92.23
128 82.00 7.93 12.00 27.07
256 210.00 129.86 77.00 92.13
1024 978.00 544.53 70.00 93.27
1518 1472.00 452.31 38.00 58.01

Table: CPSW UDP Egress Throughput


Frame Size(bytes) am64xx-hsevm: UDP Datagram Size(bytes) (LOCAL_SEND_SIZE) am64xx-hsevm: THROUGHPUT (Mbits/sec) am64xx-hsevm: Packets Per Second (kPPS) am64xx-hsevm: CPU Load % (LOCAL_CPU_UTIL)
64 18.00 1.11 8.00 14.31
128 82.00 5.77 9.00 15.96
256 210.00 16.13 10.00 6.57
1024 978.00 76.67 10.00 18.20
1518 1472.00 115.40 10.00 9.84

Table: CPSW UDP Ingress Throughput (0% loss)


Frame Size(bytes) am64xx-hsevm: UDP Datagram Size(bytes) (LOCAL_SEND_SIZE) am64xx-hsevm: THROUGHPUT (Mbits/sec) am64xx-hsevm: Packets Per Second (kPPS) am64xx-hsevm: CPU Load % (LOCAL_CPU_UTIL) am64xx-hsevm: Packet Loss %
64 18.00 17.84 124.00 81.30 10.81
128 82.00 74.04 113.00 79.11 0.72
256 210.00 204.38 122.00 84.93 40.95
1024 978.00 893.41 114.00 90.90 4.39
1518 1472.00 956.15 81.00 81.09 0.10

Table: CPSW UDP Ingress Throughput (possible loss)


2.4.1.2.2. ICSSG Ethernet Driver

TCP Bidirectional Throughput

Command Used am64xx-hsevm: THROUGHPUT (Mbits/sec) am64xx-hsevm: CPU Load % (LOCAL_CPU_UTIL)
netperf -H 192.168.2.1 -j -c -C -l 60 -t TCP_STREAM; netperf -H 192.168.2.1 -j -c -C -l 60 -t TCP_MAERTS 238.35 78.00

Table: ICSSG TCP Bidirectional Throughput


Frame Size(bytes) am64xx-hsevm: UDP Datagram Size(bytes) (LOCAL_SEND_SIZE) am64xx-hsevm: THROUGHPUT (Mbits/sec) am64xx-hsevm: Packets Per Second (kPPS) am64xx-hsevm: CPU Load %
64 18.00 1.97 14.00 18.50
128 82.00 14.56 22.00 24.32
1024 978.00 93.88 12.00 21.55
1518 1472.00 313.99 27.00 62.65

Table: ICSSG UDP Ingress Throughput (0% loss)


2.4.1.2.3. IPSec Software Performance

Algorithm am64xx-hsevm: Throughput (Mbps) am64xx-hsevm: Packets/Sec am64xx-hsevm: CPU Load
3des 51.20 4.00 50.93
aes128 0.50 0.00 82.27