You are here: Home / Projects / OSADL QA Farm Real-time / 
2024-07-13 - 18:55

Dates and Events:

OSADL Articles:

2023-11-12 12:00

Open Source License Obligations Checklists even better now

Import the checklists to other tools, create context diffs and merged lists

2023-03-01 12:00

Embedded Linux distributions

Results of the online "wish list"

2022-01-13 12:00

Phase #3 of OSADL project on OPC UA PubSub over TSN successfully completed

Another important milestone on the way to interoperable Open Source real-time Ethernet has been reached

2021-02-09 12:00

Open Source OPC UA PubSub over TSN project phase #3 launched

Letter of Intent with call for participation is now available

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

Continuous worst-case latency monitoring

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

The newly available long-term monitoring of a system's worst-case interrupt and scheduling latency permits to record the latency of every single wakeup sequence of real-time processes throughout the uptime of the system. The plot below is generated at one of the OSADL testing labs and updated every couple of minutes. Background, kernel configuration and other details of internal latency monitoring are outlined in this abstract and explained in more detail in this paper (PDF format) of the Twelfth Real Time Linux Workshop.

Last update 2 minutes ago

Continuous worst-case latency monitoring
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:".

Generation of CPU load

Between 7 a.m. and 1 p.m. and between 7 p.m. and 1 a.m., a simulated application scenario is running using cyclictest at priority 99 with a cycle interval of 200 µs and a user program at normal priority that creates burst loads of memory, filesystem and network accesses. The particular cyclictest command is specified in every system's profile referenced above and on the next page. The load generator results in an average CPU load of 0.2 and a network bandwidth of about 8 Mb/s per system. Histogram data obtained from the cyclictest runs are used to create latency plots (aka Linux real-time plots) that are also referenced above and on the next page. Profiles and latency plots are updated twice a day.