The following changes can be made to the ComfilePi to improve the the real-time performance of a program running on it.

• Set the CPU governor to performance to keep the CPU's frequency constant
• Isolate a real-time program to one of the 4 CPU cores
• Schedule the program as real-time with high priority
• Disable realtime throttling.
• Use a real-time kernel

Run the following commands in a terminal to set the CPU governor to performance to prevent the system from dynamically changing the CPU frequency.

sudo apt install cpufrequtils
sudo cpufreq-set -g performance

Operating system utilities should report the frequency at 1.2GHz.

pi@raspberrypi:~ $ sudo cat /sys/devices/system/cpu/cpu[0-3]/cpufreq/cpuinfo_cur_freq
1500000
1500000
1500000
1500000
pi@raspberrypi:~ $ vcgencmd measure_clock arm
frequency(48)=1500398464

First, add isolcpus=nohz,domain,managed_irq,3 irqaffinity=0-2 nohz_full=3 rcu_nocbs=3 to the /boot/cmdline.txt file. This will prevent Linux from allocating the 4th core to most process, interrupt handlers, and kernel threads. Reboot for the change to take effect. See the Linux kernel documentation for more information on these kernel arguments.

Then use taskset to have Linux run a program, in this case a program called test, on the 4th core. The program will have that core all to itself. See the taskset man page for more information.

sudo taskset -cp 3 `pidof test`

Core isolation can also be achieved using cpusets. See the following resources for more information:

• Linux kernel documentation on cpusets
• cpuset utility package documentation

This will configure the process with FIFO scheduling, and increase its priority to the maximum. Other options are possible allowing one to tune the scheduling algorithm to their specific use case. See the chrt man page for more information.

sudo chrt -f -p 99 `pidof test`

htop will report the process with a priority of RT.

When using FIFO scheduling, it may be necessary to disable realtime throttling.

sudo sh -c "echo -1 > /proc/sys/kernel/sched_rt_runtime_us"

However, this is a blunt instrument because it disables realtime throttling on all cores. Instead, to implement precise timing, it may be best to introduce a sleep along with a spin-wait for greater precision. For more information, refer to this description.

In this test, a program is created to output a 100µs alternating pulse (500kHz) on one of the ComfilePI's GPIO pins. The program uses the gpiod library.

#include <gpiod.h>
#include <cstdio>
#include <chrono>
#include <unistd.h>
 
using namespace std::chrono;
 
void delay(uint32_t us)
{
    auto t1 = steady_clock::now();
    auto t2 = t1 + microseconds(us);
    this_thread::sleep_for(10us);
    while (steady_clock::now() < t2);
}
 
int main(int argc, char **argv)
{
    const char *chipname = "gpiochip0";
    struct gpiod_chip *chip;
    struct gpiod_line *line16;
 
    // Open GPIO16
    chip = gpiod_chip_open_by_name(chipname);
    line16 = gpiod_chip_get_line(chip, 16);
    gpiod_line_request_output(line16, "realtime", 0);
 
    // Toggle GPIO every 100us
    while (true)
    {
        gpiod_line_set_value(line16, true);
        delay(50);
        gpiod_line_set_value(line16, false);
        delay(50);
    }
 
    // Release lines and chip
    gpiod_line_release(line16);
    gpiod_chip_close(chip);
 
    return 0;
}

Compile with…

# Install the gpiod library if necessary
# sudo apt install libgpiod-dev

# Compile the program
g++ -O3 test.cpp -lgpiod -o test

An oscilloscope shows the pulse as physically generated by the ComfilePi.

While the real-time program is executing, a separate process is run to simulate browsing the web using the Chromium browser. The goal is to measure any disruption to the real-time process that may occur by an operator interacting with a user interface.

#!/bin/bash
 
while true
do
    chromium-browser http://comfiletech.com &
    sleep 15s
    killall chromium-browser
    sleep 5s
done

Due to the CPU isolation configuration explained above, Linux will allocate the Chromium browser only to the first 3 cores.

An external data capture instrument is used to measure the consistency of the pulse. Any deviation from the 100µs, specified in the program's source code, is jitter. The jitter is recorded according to the number of times it occurs over the duration of the test.

The test is conducted under 3 configurations:

1. An ordinary kernel with no CPU isolation or real-time scheduling
2. An ordinary kernel with CPU isolation and real-time scheduling
3. A real-time kernel with CPU isolation and real-time scheduling

As can be seen in the chart above, the ordinary kernel, without any CPU isolation or real-time scheduling, operates with excessive jitter and would likely not be suitable for any real-time application. However, by taking a few measures to optimize a process for real-time performance, it is possible to reduce jitter potentially below 50µs which may be acceptable for some real-time use cases. Without the intentional disturbance introduced by running the web browser, the performance is better.

Although the real-time kernel can reduce jitter, it trades off overall performance throughput. Using the real-time kernel may cause the system to boot slower and run some applications with a mild performance penalty, but it will provide more deterministic behavior.

• Measuring the Impacts of the Preempt-RT Patch

ComfilePi - Industrial Raspberry Pi Panel PC