Pigeon real-time tests

1. Introduction

This page aims to present the real-time tests of Pigeon RB100-CM3.

2. Global setup

During the test, we use Pigeon RB100-CM3 with installed latest available Raspbian Lite (2017-04-10) and kernel with PREEMPT_RT patches (kernel version 4.4.50-rt63-v7+).

Real-time tests are only meaningful under heavy stress to guarantee to find worst-case latencies. The following tools were used to stress the system:

stress --cpu 4,
ping -f IP_ADDRESS.

3. Results of tests

3.1. Latency from external signal

This test reproduces a common use case. The first GPIO works as input (GPIO1) and the second GPIO is output (GPIO0). Output state changes according to input. The wiring diagram is below.

The oscilloscope was set to trigger a rising edge on CH1. During all measurements oscilloscope had "Persist" option set to "Infinity", to find worst-case latencies. On all the following oscilloscope snapshots input GPIO signal is yellow and output GPIO signal is blue.

3.1.1. User space pool GPIO

In user space to make the test we use simple pool GPIO example software with processor direct register access [1]. The main loop looks like below

while (1)
{
if (GET_GPIO(GPIO_NR_IN))
GPIO_SET = 1;
else
GPIO_CLR = 1;
}

First, we made the measurement for non real-time policy [2] and no load. On the following oscilloscope snapshot, we can see what we get after 20 minutes: policy = SCHED_OTHER, priority = 0, no stress, time base = 100 us.

It looks not bad - maximum latency is about 50us. Let see what will happed when we add stress. On the following oscilloscope snapshot, we can see what we get after 5 minutes: policy = SCHED_OTHER, priority = 0, stress on, time base = 100 us.

Now it looks hopeless. Maximum latency is greater than 500us.

Next, we made the measurement for real-time policy and stress. On the following oscilloscope snapshot, we can see what we get after 3 hours: policy = SCHED_FIFO, priority = 99, stress on, time base = 100 us.

In this case, maximum latency is below 50us - very good result.

3.1.2. User space interrupt

For user space interrupt measurement we use WiringPi library [3] :

wiringPiISR(GPIO_NR_IN, INT_EDGE_BOTH, &gpio_int)

gpio_int function looks like below

void gpio_int(void)
{
if (digitalRead(GPIO_NR_IN))
digitalWrite(GPIO_NR_OUT, 1);
else
digitalWrite(GPIO_NR_OUT, 0);
}

On the following oscilloscope snapshot, we can see what we get after 2 hours: policy = SCHED_RR, priority = 55, stress on, time base = 100 us. Note. WiringPi library sets thread (interrupt handler) policy to SCHED_RR and priority to 55 (see InterruptHandler function in the file wiringPi.c).

As you can see from above oscilloscope snapshot maximum latency, in this case, is about 240us.

3.1.3. Kernel space interrupt GPIO

For kernel space test, we use kernel module written by Marcin Bis [4] with little modification of pins definitions. This module uses GPIO interrupt. On the following oscilloscope snapshot, we can see what we get after 5 hours: policy = SCHED_FIFO (default for interrupt), priority = 50 (default for interrupt), stress on, time base = 100 us.

In this case, maximum latency is about 110 us. There is possible to increase the priority of the interrupt (chrt command), but we did not notice in this case a significant reduction of maximum latency.

3.2. Timer latency

This test measures the latency using cyclictest [5] a high-resolution test program. It is part of the test suite rt-tests [6]. To create a latency plot from cyclictest histogram data we used mklatencyplot.bash script [7]. On the following chart, we can see what we get after five hours: