2020-08-03 - 14:34
OSADL Projects

OSADL QA Farm on Real-time of Mainline Linux

About - Hardware - CPUs - Benchmarks - Graphics - Benchmarks - Kernels - Boards/Distros - Latency monitoring - Latency plots - System data - Profiles - Compare - Awards

Real-time host and network load

Wakeup latency of all systems - Real-time optimization - Peer-to-peer UDP duplex link - OPC UA PubSub over TSN - Powerlink - Ethercat - Network load - kvm - Sleep states

This test was setup to investigate the effect of artificial heavy non-real time network load on the real-time capabilities of a system. It is carried out on a TI TMDXIDK5728 dual-core v7 ARM processor (rack #a/slot #5 at shadow position) that is equipped with four Ethernet connectors eth0 to eth3. Flood ping data are sent over a loopback connection from eth2 to eth3 starting at 7:20 am and pm while cyclictest is continuously challenging the system. The command line of the flood ping command is

ping -f -c 12000000 -s 56   -I eth2 resulting 5-min consecutive worst-case latency values of the two processor cores are recorded separately using the kernel built-in latency histograms. This measurement takes about 20 minutes. Thereafter, for 10 minutes no data are sent followed by another measurement with the same principle as in the first one except that the payload of the ping packets is increased to 65506 Bytes and the cycle count decreased accordingly:

ping -f -c 120000   -s 65506 -I eth2

The recordings below show the network traffic of the two phys eth2 and eth3 as well as the CPU load and the continuously monitored wakeup latency of the system. The test is successful, if the system's real-time capabilities as determined by the worst-case wakeup latency remain unaffected or only slightly affected at the time of sending flood ping packets over the line.

Last update 2 minutes ago

Resulting outgoing traffic at eth2
Resulting incoming traffic at eth3
CPU load
Note the increase of softirq related CPU load during small-packet flood ping.
Worst-case wakeup latency
Please note that the recorded values represent maxima of 5-min intervals. Thus, the data in the columns labeled "Min:" and "Avg:" should not be considered; the only relevant result is the maximum of consecutive 5-min maxima at the rightmost column labeled "Max:".