Content

• Introduction
• Basic Setup Linux on the NVIDIA Jetson AGX Thor
• Stage 1: EtherCAT with minimal effort
• Stage 2: EtherCAT with high efficiency
• Stage 3: EtherCAT with highest performance
• Summary

“Designed for the future of integrated Edge AI and general robotics.” This is how NVIDIA announced the new NVIDIA® Jetson™ AGX Thor computing platform.

Real-time communication is essential for robotics applications. Fast and dynamic movements, short reaction times to sensor events, and rapid actuator response are just some of the key requirements in robotic systems.

This is where acontis EC-Master excels. The EtherCAT MainDevice Software Stack delivers ultra-high performance with minimal CPU load while also supporting hard real-time operation.

This blog demonstrates how to make an EtherCAT controller on an NVIDIA Jetson AGX Thor real-time capable within a Linux environment. To illustrate the impact of different optimization levels, the content is divided into three stages. Stage 1, Stage 2, and Stage 3 represent increasing levels of system optimization, as shown in Figure 1. Starting with minimal effort, each stage introduces additional optimizations. The performance results of each stage are compared, allowing the appropriate level to be selected based on application requirements.

Figure 1: Different optimization stages of EtherCAT performance

NVIDIA offers a Quick Start Guide which ensures a smooth Linux installation with the JetPack 7.0. The Linux system is delivered with an SMP PREEMPT kernel.

Before proceeding, it is helpful to review the three optimization stages. Not all applications require maximum real-time performance. In many cases, a plug-and-play setup is sufficient to bring EtherCAT communication into Operational state with minimal effort, referred to here as Stage 1. Other applications place higher demands on performance and determinism, requiring additional system configuration, referred to as Stage 2. For the most demanding real-time requirements, further optimization is necessary, referred to as Stage 3.

For each stage, system performance is measured using the acontis performance measurement reference setup connected to the NVIDIA Jetson AGX Thor via Ethernet, as shown in Figure 2.

Figure 2: Test system with NVIDIA Jetson AGX Thor and Beckhoff SubDevices

The acontis performance measurement reference setup consists of:

• EtherCAT coupler (Beckhoff EK1100)
• 2x EtherCAT 4-channel digital output Terminal (Beckhoff EL2004)
• 2x EtherCAT 4-channel digital input Terminal (Beckhoff EL1014)
• EtherCAT 2-channel analog output Terminal (Beckhoff EL4132)
• EtherCAT extension (Beckhoff EK1110)

The EC-Master sample application EcMasterDemoDc is used for this test setup. This application supports the Distributed Clock functionality and enables detailed performance analysis using the -dcmlog option.

Before testing begins, the meaning of real-time performance must be clarified, as it varies depending on application requirements. Some systems focus on supporting a large number of SubDevices, while others prioritize the total amount of cyclic and acyclic process data. Optional EtherCAT features such as Distributed Clocks, Hot Connect, or Multiple Update Rates also influence performance. In addition, the EtherCAT application itself has a significant impact. The method in which the application accesses the EC-Master API directly affects the real-time capability of the system.

BBeyond these considerations, two key metrics are typically used to evaluate real-time performance:

1. CPU Load:
CPU load indicates the amount of processing time required by EC-Master to handle EtherCAT communication. Lower CPU load leaves more processing capacity available for other system tasks.

2. Jitter:
Jitter describes variations in the timing of cyclic EtherCAT frames. Low jitter is essential for precise synchronization and control.

Stage 1 starts with an unmodified system installed according to the NVIDIA Quick Start Guide. On the acontis side, the complete folder containing the EcMasterDemoDc application and the generic Linux SOCK_RAW driver is saved to the system.

Figure 3: Architecture of SockRAW

In this setup, the EC-Master stack communicates with SubDevices using the acontis SOCK_RAW network interface module, as shown in Figure 3. This module interfaces with the Linux network stack and driver code and exchanges EtherCAT frames via the standard Ethernet MAC. Due to the multiple software layers involved and the lack of real-time kernel configuration, limited real-time performance is expected.

The EC-Master application is started using the following command:

$ sudo ./EcMasterDemoDc -f eni.xml -sockraw enP2p1s0 -v 4 -b 1000 -perf -dcmlog

EcMasterDemoDc is using the ENI (EtherCAT Network Information) file with the configuration of the SubDevices for the performance reference (-f eni.xml) and the application is using the module SOCK_RAW (-sockraw) with the name of the network interface as following parameter. We set the verbosity level to a high level so we can see plenty of information as console output messages (-v). For our test, we use the cycle time of 1 ms (1000 us) which is specified with the parameter -b. Parameter -perf enables the performance measurement and with the function -dcmlog, we are able to print out the detailed performance data into a csv file.

Below in Figure 4, the results of the test with the EtherCAT communication show a quite high jitter of about +/- 330 µs (see deviation of min. and max. Cycle time). The whole job of the EC-Master last about 10,4 µs of the specified CPU cycle time of 1000µs. In other words, the EC-Master needs around 1,04% (10,4 µs of 1000 µs) of the CPU load – these are amazing performance values. So the average values are quite good, but we see high maximum values due to the lack of the Linux real-time kernel.

Figure 4 performance measurement results – Stage 1

The cyclic jitter chart recorded using -dcmlog, shown in Figure 5, displays the controller error (CtlErr). These values (in nanoseconds) represent the current deviation of the DCM controller. Several peaks are visible, which can lead to EtherCAT frame loss and degraded system stability.

Figure 5 Cyclic frame jitter in ns – Stage 1

In summary, Stage 1 delivers very low CPU load but exhibits jitter values that are too high (up to 33% of the cycle time) for many real-time applications. Such jitter may be acceptable for longer cycle times, for example 5 ms.

Stage 2 introduces real-time optimizations at the Linux kernel level. JetPack 7.0 already includes real-time kernel support, which must be activated and configured.

As described in a previous acontis blog post, Developing Compact and Powerful EtherCAT Controllers with acontis EC-Master on the NVIDIA Jetson Orin Nano , the RT kernel packages for the Thor platform are installed using the following command:

$ sudo apt install nvidia-l4t-rt-kernel nvidia-l4t-rt-kernel-headers nvidia-l4t-rt-kernel-oot-modules nvidia-l4t-display-rt-kernel nvidia-l4t-rt-kernel-openrm

After rebooting, the real-time kernel is active. This procedure is also described in the NVIDIA Jetson Linux Developer Guide.

To further improve real-time behavior, several kernel settings must be adjusted. The kernel configuration file is opened using:

$ sudo nano /boot/extlinux/etxlinux.conf

By adding the following kernel boot parameter to the real-time kernel configuration, CPU core number 3 is isolated exclusively for EtherCAT communication:

isolcpus=3

After adding this parameter, the configuration file is saved, and the system is restarted. Once the reboot is complete, the active kernel parameters can be verified using:

$ cat /proc/cmdline

In this setup, the Kernel config appears as follows:

root=PARTUUID=b7a98bc4-af54-4ba7-b42b-01791f6ebacf rw rootwait rootfstype=ext4 mminit_loglevel=4 earlycon=tegra_utc,mmio32,0xc5a0000 console=tty0 console=ttyUTC0,115200 clk_ignore_unused firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb efi=runtime bl_prof_dataptr=6225920@0x2008010000 bl_prof_ro_ptr=65536@0x20 isolcpus=3 bl_prof_dataptr=6225920@0x2008010000 bl_prof_ro_ptr=65536@0x2008000000

Next, the CPU frequency scaling governor is configured for all 14 CPU cores of the Jetson AGX Thor. Each core is set to operate in performance mode at maximum frequency to ensure maximum computing power.

This configuration is applied using the following commands:

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
…
echo performance > /sys/devices/system/cpu/cpu13/cpufreq/scaling_governor

With the real-time kernel configured and CPU isolation enabled, the EC-Master application is started again using the following command:

$ sudo ./ EcMasterDemoDc -f eni.xml -sockraw 1 1 -v 4 -a 3 -b 1000 -perf -dcmlog

The -a command line argument specifies CPU affinity. In this case, EC-Master is bound exclusively to CPU core 3. This ensures that EtherCAT communication runs independently of other system processes and further improves real-time behavior.

The performance results are shown in Figure 6. Compared to Stage 1, jitter is reduced by more than half, to approximately ±125 µs.

Figure 6: performance measurement results – Stage 2

Although this represents a significant improvement, the jitter values are still too high for demanding hard real-time applications, especially those using Distributed Clocks. This is also visible in the cyclic jitter chart shown in Figure 7, where remaining peaks can still be observed.

Figure 7: Cyclic frame jitter in ns – Stage 2

Stage 3 focuses on achieving maximum real-time performance by replacing the standard Linux Ethernet driver. On the Jetson AGX Thor Development Kit, one of the onboard RJ45 Ethernet interfaces is based on a Realtek Ethernet controller.

To enable deterministic real-time communication, the standard Linux Ethernet driver must be replaced. A dedicated real-time Ethernet driver for this Realtek controller is provided by acontis and is specifically developed and tested for EtherCAT applications. The driver package is copied to a working directory in user space.

To ensure that the acontis real-time driver is used, the standard Linux driver must be removed from the Ethernet controller. This is achieved by blacklisting the default driver using the following commands:

echo blacklist r8126 | sudo tee -a /etc/modprobe.d/blacklist.conf
update-initramfs -k all -u
sudo reboot

By blacklisting the standard driver, it is no longer loaded into the kernel after the system reboot.

To allow direct hardware access between the Ethernet driver and the Ethernet MAC, the atemsys kernel module must be loaded. The atemsys module specific to the Jetson AGX Thor platform is downloaded from the acontis download page and placed in the working directory.

The module is loaded using the following command:

$ sudo insmod atemsys.ko

This setup enables direct hardware access for the acontis real-time Ethernet driver and eliminates unnecessary software layers. As a result, both real-time behavior and CPU efficiency are significantly improved. An overview of this architecture is shown in Figure 8.

Figure 8: Architecture of acontis real-time driver

The EC-Master application is then started using the acontis real-time Ethernet driver for the Realtek controller:

$ sudo ./EcMasterDemoDc -f eni.xml -rtl8169 1 1 -v 4 -a 3 -b 1000 -perf -dcmlog

The configuration is similar to the previous stage, with the key difference being the replacement of the SOCK_RAW driver with the acontis real-time Ethernet driver specified by the -rtl8169 option.

The performance results are shown in Figure 9. The system achieves a very low jitter of approximately ±6 µs, as indicated by the deviation between the minimum and maximum cycle times. The EC-Master execution time is approximately 13.8 µs of the configured 1000 µs cycle time. This corresponds to a CPU load of about 1.38 percent.

Figure 9 performance measurement results – Stage 3

The cyclic jitter chart shown in Figure 10 displays no visible peaks in the CtlErr values. This confirms stable and deterministic EtherCAT communication with no risk to system stability.

Figure 10 Cyclic frame jitter in ns – Stage 3

Since a cycle time of 1 ms is handled reliably, a shorter cycle time of 250 µs is also tested. The results are shown in Figure 11.

Figure 11 performance measurement results with cycle time of 250 µs – Stage 3

At a 250 µs cycle time, the system remains stable with low jitter. The EC-Master execution time is approximately 13.5 µs per cycle, corresponding to a CPU load of about 5.4 percent. These results demonstrate that EC-Master can reliably handle cycle times of 250 µs and below on the Jetson AGX Thor platform.