Pma tools/jitter

Definition

Jitter in execution can happen because of underline hardware or OS interferences. These interferences take out cycles from real-time applications such as packet processing workloads.

Jitter implication on packet processing

Packet processing workloads need to account for maximum jitter. When CPU is not perform packet processing due to hardware or OS interferences, the system needs to buffer the packets. When jitter is excessive, the system may run out of buffers and starting to drop packets.

Build and Execution

To build the jitter program, simply clone the pma_tools repo and run make command in jitter folder.

To run the jitter program, first check the intended core is idle, and use taskset to pin jitter program on the idle core. (i.e. taskset -c 2 ./jitter)

Measurement and Analysis

This benchmark measures variation in execution for a userspace dummy loop repeatedly to indicate jitter in the platform.

If Inst_Jitter column from jitter program is reporting >10,000 cycles, user may want to optimize hardware/OS to minimize this value.

Jitter test program overview

Jitter test program simulated an userspace program in a tightly polling loop (like DPDK). It wants to execute a piece of code continuously with minimal interruption from OS or other userspace processes.

Jitter test program executes a simple arithmetic operations (dummyop) in a loop (~80000). Measure rdtsc (cycles) for the loop execution time. If there is no OS/process interference, it should take fix amount of time to execute these loops every time. Currently, in 20,000 samples interval (each sample is 80,000 dummyop), the jitter varies from 5K cycles to 70K cycles. The goal is to keep it under control under 10K at all time.

Reference results