Raspberry Pi 4B LinuxCNC: Resolving the “Unexpected realtime delay on task0…” Startup Error

After launching LinuxCNC, it consistently reported Unexpected realtime delay on task0 with period 500000. Despite this startup error, LinuxCNC otherwise appeared to operate normally. I am documenting the AI-assisted troubleshooting process I used to resolve this error. Again, this is not a tutorial, but rather a record of my learning progression.

🐧 Index of the Complete Series.


Raspberry Pi 4B LinuxCNC: Resolving the “Unexpected realtime delay on task0…” Startup Error

I am just an ordinary computer programmer and not trained in any of the electronic engineering disciplines. This LinuxCNC project is a learning process for me. This post is not meant to be a tutorial or instructional guide; it is my own documentation so I will not forget what I have learned.

I am not to be held responsible for any damages or injuries resulting from using the information presented in this post.

The full text of the error is:

Unexpected realtime delay on task0 with period 500000

This message will only display once per session.

Run the Latency Test and resolve before continuing.

Please see the screenshot below, which shows this error.

Unexpected realtime delay on task0…

500000 is the value of the SERVO_PERIOD setting in the main Test_XYZ.ini file. This corresponds to 500,000 nanoseconds (500 µs).

💡 I previously performed the latency tests as documented in this post Raspberry Pi 4B: LinuxCNC Max Jitter or Latency Test.

This problem has been present since the first day, but I have largely ignored it. Now that I have assembled all of the essential electronic components needed to build a functional, testable machine, it is time to investigate and resolve it.

This issue appears to be a common problem across different hardware environments. There are numerous related discussions on different social media platforms. Two examples from the official LinuxCNC forum are:

The following commands show the kernel information for my Raspberry Pi 4B.

$ cat /proc/version

The output is:

Linux version 6.6.77-rt50-v8-behai-rt-build+ (behai@picnc) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_RT Tue Feb 18 12:45:31 AEDT 2025

$ hostnamectl

The output is:

 Static hostname: picnc
       Icon name: computer
      Machine ID: 9018........................da35
         Boot ID: 1909........................5104
Operating System: Debian GNU/Linux 12 (bookworm)
          Kernel: Linux 6.6.77-rt50-v8-behai-rt-build+
    Architecture: arm64

❶ I was told that task0 essentially corresponds to the servo-thread. It is the primary real-time thread responsible for running the motion control calculations, monitoring limit switches, and performing other time-critical tasks. This error indicates that the system was busy doing something, causing task0 to miss its scheduled execution every 500,000 nanoseconds; in other words, it woke up late.

💥 I can’t remember exactly why I set SERVO_PERIOD to 500,000 nanoseconds.

❷ I first worked through the following steps suggested by various AI assistants. They only partially resolved the issue.

● Checked and verified that in the main Test_XYZ.ini file, there is no entry for BASE_PERIOD, since Mesa 7I96S card does not use this entry. This was a brand-new configuration generated using the Mesa Configuration Wizard (PnCconf), so the absence of BASE_PERIOD is expected.

● In the main Test_XYZ.hal file, I verified that:

There is no entry attached to base-thread.
There are no loadrt threads…, loadrt stepgen…, loadrt encoder…, and loadrt pwmgen… entries.
There are no addf hm2_7i96s.0.read servo-thread and addf hm2_7i96s.0.write servo-thread entries.

● 💡 In the main Test_XYZ.ini file, I updated SERVO_PERIOD to 1,000,000. I have observed that:

After shutting down every other application, I relaunched LinuxCNC. With only LinuxCNC running, the error was not reported. I repeated this test several times, and the behaviour was consistent.
With only the File Manager running, relaunched LinuxCNC. The error was reported with Unexpected realtime delay on task0 with period 1000000. I have also repeated this several times, the behaviour was consistent.

● Next, 💡 in the main Test_XYZ.ini file, I updated SERVO_PERIOD to 2,000,000. I have observed that, with the File Manager running, LinuxCNC did not raise this error. The behaviour was also consistent. However, when the Terminal was also running, the error was reported.

❸ ✔️ Disable IPv6 networking and apply kernel isolcpus. I found this solution to be the most reliable.

⓵ Disable IPv6 networking — the Mesa 7I96S card communicates with the Raspberry Pi through Ethernet using a fixed address. Disabling IPv6 removes unnecessary IPv6 networking activity, which may reduce background network processing and help avoid delays in the servo-thread.

Update the kernel command-line file to instruct the boot process to disable IPv6 networking. In Debian GNU/Linux 12 (bookworm), this file is /boot/firmware/cmdline.txt:

$ sudo nano /boot/firmware/cmdline.txt

Add the following parameter, preceded by a space, to the end of the existing line. This file should contain only a single line.

network.disable_ipv6=1

⓶ Kernel isolcpus — instructing Linux to isolate one or more CPU cores from normal scheduler activity, allowing LinuxCNC realtime tasks to run with less interference.

The Raspberry Pi 4B has 4 CPU cores. To determine the number of cores, run the command nproc. By default, the operating system schedules normal background tasks, such as networking, the graphical user interface (GUI), and system maintenance, on the same CPU cores that LinuxCNC uses for realtime tasks.

For my Pi 4B, isolating a core for LinuxCNC realtime processing was the most effective step in eliminating the Unexpected realtime delay errors.

I isolated Core 3 by adding the following parameters, preceded by a space, to the end of the existing line in the kernel command-line file /boot/firmware/cmdline.txt:

isolcpus=3 nohz_full=3 rcu_nocbs=3

Please note:

isolcpus=3: removes CPU 3 from normal scheduler load balancing. Not all kernel activity is removed from that CPU.
nohz_full=3: enables tickless operation on CPU 3 when possible.
rcu_nocbs=3: moves RCU callback processing away from CPU 3.

Whenever the kernel command-line file is updated, the machine must be rebooted for the new parameters to take effect. After rebooting, the boot parameters can be verified with the command cat /proc/cmdline.

⓷ In the main Test_XYZ.ini file, restore SERVO_PERIOD to 1,000,000 nanoseconds.

I observed the following:

With the File Manager and Mousepad Text Editor running, and Test_XYZ.ini loaded, the error did not occur.
With the File Manager and Mousepad Text Editor running, and Test_XYZ.ini loaded, and with Chrome running and the GitHub page loaded, the error did occur. This is understandable because a web browser introduces additional system activity, and it should not affect normal LinuxCNC operation.
With the File Manager and Mousepad Text Editor running, and Test_XYZ.ini loaded, and with the Thonny Python IDE running without any files loaded, the error did not occur.

I am happy with this outcome. I consider the issue resolved for normal LinuxCNC operation.

❹ NetworkManager, the Ethernet Interface, and Network Latency.

The initial setup process for the Mesa 7I96S card, as described in the article Raspberry Pi 4B LinuxCNC: Initial Setup for the Mesa 7I96S Ethernet Motion Control, means that the Ethernet interface was configured using the traditional Linux network configuration method, which bypasses NetworkManager completely. NetworkManager is not controlling this connection. Therefore, it is unlikely to be the cause of the observed network latency issue between the Pi and the Mesa 7I96S card.

We can query the status of network devices using the command:

$ nmcli device status

behai@picnc:~ $ nmcli device status
DEVICE         TYPE      STATE                   CONNECTION
wlan0          wifi      connected               preconfigured
lo             loopback  connected (externally)  lo
p2p-dev-wlan0  wifi-p2p  disconnected            --
eth0           ethernet  unmanaged               --
behai@picnc:~ $

💡 Please note the line eth0 ethernet unmanaged.

We observe an important LinuxCNC principle: a deterministic real-time system does not necessarily require zero network traffic; it requires predictable timing.

❺ All relevant configuration files have been committed to GitHub and are available for reference:

❻ I have never gone through a troubleshooting process like this before. I find it very interesting. Hopefully, this issue has now been resolved. I understand that the Raspberry Pi 5 is much more powerful, even though it still has only four CPU cores. If I ever finish building this machine, I might consider upgrading to a Raspberry Pi 5 8GB model.

Thank you for reading. I hope you find this breakdown helpful for your own setups. Take care and stay safe!

✿✿✿

Feature image source: