INtime Node Jitter Behaviour and RMPNetwork

INtime RTOS
1

RMP 11.0.0, INtime version 7.1.25030.3

Hi community,

I would like to further my understanding of how Jitter accumulates on different PCs and how it ultimately affects the RMPNetwork.

We are currently evaluating a case involving an Omron NX-ECC201 I/O Coupler (linked using Mdp.xml) within an EtherCAT network and would appreciate your feedback to help us better understand the observed behaviour.

Test Setup
The RMPnetwork containing the Omron NX-ECC201 I/O Coupler was tested on two devices where both have relatively similar processing capability with the laptop being the newer platform.

IPC - Intel 12th Gen i9 Processor
Laptop - Intel Core Ultra 7 255H Processor **newer generation

Observed Behaviour
With Omron NX-ECC201 I/O Coupler included in the network

  • IPC:
    • RMPNetwork starts and operates stably
  • Laptop:
    • Unable to reliably start the network due to timeout
    • Intermittent network disconnection observed if network started (typically after 2–3 seconds or after several minutes)
    • Suspect that the Omron I/O Coupler transitions into SafeOP state causing Network Shutdown due to slight Jitter (Eg. Default 1000us cycle time but 1100 or 1200us occured for one cycle)

Our current suspicion is that slight Jitter variation may be causing the coupler to detect cyclic timing deviations, potentially due to stricter cycle time tolerance on the Omron device.

If the I/O Coupler is taken out, the RMPNetwork is stable for both PC and laptop. This unstable behaviour appears isolated to scenarios where the I/O Coupler is present as no network disconnection issue occurs when the I/O Coupler is taken out.

Steps taken

  • Performed BIOS optimization on the laptop per RSI’s BIOS optimization guide
  • Upgraded to latest INtime ver 7.2.26104-1 to test out Frequency Scaling using HWP and set core for NodeA to efficient, guaranteed or highest performance frequency setting to test if disconnection still occurs

Despite these adjustments, the laptop still experiences timeout issues and intermittent network disconnection when the Omron I/O Coupler is included.

To further improve our understanding of INtime Nodes and Jitter behaviour, we would appreciate your guidance on the following:

  1. How does Jitter differ across devices (Eg. IPC and laptop) even when both systems have similar processing specifications?
  2. What hardware or system-level factors commonly contribute to Jitter differences between platforms with comparable performance?
  3. Does EtherCAT devices have varying tolerance levels toward cyclic timing variation and Jitter? (As the network is able to start and no disconnection occurs for other nodes when I/O Coupler is taken out from the network on the laptop)

Your guidance and clarification is much appreciated. Thank you!

1 Like
2

Hi @gregory,

Jitter is the inconsistency of the regular cyclic frame that we send out on the network. This is normally caused by a system designed with other priorities than high-end performance. Laptops often have more aggressive power and thermal management, hybrid P/E core behavior, firmware/SMM activity, C-states/turbo/HWP behavior, PCIe power management, and sometimes less deterministic behavior. This isn’t exclusively a laptop problem, but they are often going to be the worst offenders. System tuning can often vastly improve performance.

Please check out this guide: RMP PC hardware and performance requirements

Yes, nodes vary in tolerance and response. While jitter doesn’t really accumulate, the watchdogs that trigger a node transitioning to SafeOp do respond to the frequency caused by jitter events. Some nodes have watchdogs, and some don’t. They also aren’t always configured in the same ways.

1 Like
3

Hi @jacob,

Thank you for the explanation regarding Jitter and the differences of factors contributing to Jitter across devices.

We generally follow the RMP PC hardware and performance requirements guide for BIOS optimization. However, we would like to seek further clarification for newer generation Intel processors (such as Intel 12th to 13th Gen onwards), particularly processors with the hybrid architecture with Performance cores (P cores) and Efficiency cores (E cores):

Do we still ensure Intel SpeedStep, Intel Speed Shift Technology and Turbo Boost remains disabled which will limit the frequency of the cores to base clock frequency

or

Enable these settings per Tenasys’ guide for Frequency Scaling where Intel 13th gen onwards are recommended to turn these settings on for running cores at higher clock speed

Much appreciated for your guidance on the recommended processor frequency settings and system tuning settings for improving EtherCAT network stability and minimizing Jitter. Thank you!

1 Like
4

Hi @gregory,

For 12th Gen and newer Intel Core processors, TenAsys recommends evaluating the HWP / Speed Shift approach instead. In that case, SpeedStep, Speed Shift, and Turbo Mode should remain enabled in BIOS so INtime can configure the real-time node with a fixed HWP performance request, while Windows cores can scale separately.

1 Like