Network falls through high sampling rate

[BassamAlkhiami]

Hello,

I am using SOEM on linux , using the Phoenix module “Bus Coupler AXL F BK EC – 2688899”.
I have a problem when I come to read data with 5kHz sample rate.

Using this code to test the time needed to get the Data in each cycle:

The code makes console outputs “Time Difference” for each EtherCAT cycle. The measured time includes mostly ec_receive_processdata . The call ec_send_processdata is done afterwards.

When I set in the configuration the EtherCAT to work with 4kHz, I get measured time differences of 4-6µs.

When I increase the value, e.g. to 5kHz, I get time differences about 170 μs. So it seems (?) with some higher sample rate that the network driver gets much higher latencies.

When I search for this topic in the net, I find that the main solutions seems to be the content of drvcomments.txt in the SOEM repo. There is a call of ethtool described.

When I use this command as shown in drvcomments.txt in the SOEM repo

$/usr/sbin/ethtool -C enp1s0 rx-usecs 0 rx-frames 1 tx-usecs 0 tx-frames 1

I get the following error:

            Cannot set device coalesce parameters: Unknown error 524.

Any comments or help is welcome. Main questions:

Why i get a big TimeDifference for a high sampling rate higher than 5 kHz?
Why am I not able to the device parameters with ethtool?

More information about the Ethercat controller:
$ lspci | awk '/[Nn]et/ {print $1}' | xargs -i% lspci -ks %

       01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
       Kernel driver in use: igb
       Kernel modules: igb

$ uname -a
Linux bos 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux

$/usr/sbin/ethtool enp1s0

       Supported ports: [ TP ]
       Supported link modes:   10baseT/Half 10baseT/Full
       100baseT/Half 100baseT/Full
       1000baseT/Full
       Supported pause frame use: Symmetric
       Supports auto-negotiation: Yes
       Supported FEC modes: Not reported
       Advertised link modes:  10baseT/Half 10baseT/Full
       100baseT/Half 100baseT/Full
       1000baseT/Full
       Advertised pause frame use: Symmetric
       Advertised auto-negotiation: Yes
       Advertised FEC modes: Not reported
       Speed: 100Mb/s
       Duplex: Full
       Port: Twisted Pair
       PHYAD: 1
       Transceiver: internal
       Auto-negotiation: on
       MDI-X: off (auto)
       Supports Wake-on: pumbg
       Wake-on: g
       Current message level: 0x00000007 (7)
       drv probe link
       Link detected: yes

According to the Phoenix documents the typical cycle time of the Axioline F local bus is around 10 μs.

Best regards,

[ArthurKetels]

There are some problems with your test set-up.

• system_clock::now() does not use monotonic clock source. Use direct kernel supported clock routines (as used by SOEM). The system clock can deviate and in extreme cases even reverse for a short period of time.
• You can not use console outputs in real-time code, they could delay the task in unforeseen ways.
• In general: use good programming practices with real-time code.
• Other users here posted bad real-time performance for the I210 NIC (search in this forum)
• Do not simply cut & paste ethtool arguments, first look up the paramters that are supported by the driver. Then adjust the parameters that make sense.
• You are using a standard kernel. It has no real-time guarantees at all. Please try a preempt-rt patched kernel.

[BassamAlkhiami]

ok, thanks for this information, I'll try a different test setup based on your suggestions.

[nakarlsson]

@BassamAlkhiami , can we close this issue?