Difference between revisions of "Pma tools/jitter"

From fd.io
Jump to: navigation, search
(Initial publication of jitter BKM)
 
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
Definition: OS jitter is defined as the time (CPU cycles) that are not executing workload (aka context switch out.)
 
  
Jitter implication: packet processing workloads need to account for max jitter. Whenever the CPU is not perform packet processing, we need to buffer the packets. Packets will be dropped when we run out of buffer. Often times, it's not possible to have large buffer, because these buffers are fixed size hardware.
+
== 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.
  
Ideal scenario: workload exit critical section and actively pass control for OS/other processes to make forward progress.
+
== 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.
  
Bad (current) scenario: workload in critical section and interrupted by OS or other priority process.
+
== 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 frequently reporting >10,000 cycles, user may want to optimize hardware/OS to minimize this value.
  
  
 
+
== Jitter test program overview ==
 
+
Workload Critical Section Pause Critical Section Pause ...
+
OS/other tasks sleep wake up sleep wake up ...
+
 
+
 
+
Jitter test program: jitter.c
+
 
+
Compilation: gcc -O1 -o jitter jitter.c
+
 
+
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 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.
Line 27: Line 23:
 
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.
 
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.
  
int dummyop(unsigned int loops, unsigned startval)
+
== Reference results ==
{
+
[[File:jitter_reference_output.jpg]]
    register unsigned int i,a , k;
+
    a = startval ;
+
    k = loops;
+
    for(i=0; i < k; i++)
+
    {
+
        a += (3*i + k);
+
        a &=0x7f0f0000;
+
    }
+
 
+
    return a;
+
}
+

Latest revision as of 22:39, 19 December 2017

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 frequently 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

Jitter reference output.jpg