SK-AM62: About am62 and ethercat

Hello,

hao teng said:

Ethercat task core of 2ms 32 axis was occupied by 70

hao teng said:

1ms, a single core was occupied by 100

Can you clarify what you mean by 70 and 100? Do you mean you are seeing one of the 4 A53 cores that EtherCAT task process is reaching 70% CPU load while at 2ms cycle time configuration but 100% CPU load while at 1ms configuration?

Just to confirm, you are using the SK-AM62 EVM? Additionally, what Linux SDK version are you using?

Are you setting the CPU affinity of the EtherCAT task process to a single A53 core or just running CODESYS EtherCAT in an out of box environment on AM62x?

From previous testing of CODESYS EtherCAT at 1ms cycle time configuration that I've done, in the out of box environment, the EtherCAT task process can switch between running on any of the A53 cores unless you set its CPU affinity. Even when I set most "IEC" tasks - including the EtherCAT task - to a single core, the CPU load only reaches a maximum of around 65-70%. This was what I observed on AM64x (only 2 A53 cores).

-Daolin

Daolin Qiu said:

Can you clarify what you mean by 70 and 100? Do you mean you are seeing one of the 4 A53 cores that EtherCAT task process is reaching 70% CPU load while at 2ms cycle time configuration but 100% CPU load while at 1ms configuration?

Yes, the CPU load situation is mainly checked through codesys, not through HTOP and other methods

Daolin Qiu said:

Just to confirm, you are using the SK-AM62 EVM? Additionally, what Linux SDK version are you using?

The version used is based on SDK 8.6, kernel 5.10, and does not use the latest version 9. It is not a complete sk evm, and the hardware is self-made, but Linux is still based on SDK

Daolin Qiu said:

From previous testing of CODESYS EtherCAT at 1ms cycle time configuration that I've done, in the out of box environment, the EtherCAT task process can switch between running on any of the A53 cores unless you set its CPU affinity.

Not only did we use taskset, but we also used isolcpus. Without these measures, the jitter of ethercat would be much greater. I observed that the codesys process can be assigned to multiple cores, but the ethercat task thread still exists in one core, which is determined by the configuration of the codesys IDE when issuing tasks.

Daolin Qiu said:

Even when I set most "IEC" tasks - including the EtherCAT task - to a single core, the CPU load only reaches a maximum of around 65-70%. This was what I observed on AM64x (only 2 A53 cores).

May I ask, how many slave stations did Ethercat bring with you in your test

Hi Hao Teng,

>>>May I ask, how many slave stations did Ethercat bring with you in your test

In my testing, 11 subdevices were used. These included 10x Beckhoff EL2889 and 1x Beckhoff EK1100 EtherCAT coupler.

>>>Not only did we use taskset, but we also used isolcpus. Without these measures, the jitter of ethercat would be much greater. I observed that the codesys process can be assigned to multiple cores, but the ethercat task thread still exists in one core, which is determined by the configuration of the codesys IDE when issuing tasks.

Thanks for this clarification, you are right, the EtherCAT task thread is tied to one core determined by CODESYS IDE (my previous statement was incorrect in that EtherCAT task can switch between running on any of the A53 cores). When you used taskset did you move all the other CODESYS processes (what CODESYS calls "IEC" tasks) to the same CPU core as the one running EtherCAT task?

>>>Yes, the CPU load situation is mainly checked through codesys, not through HTOP and other methods

The 100 CPU load you see at 1ms, does that occur indefinitely, periodically for a short duration, or sporadically/intermittently?

-Daolin

Daolin Qiu said:

When you used taskset did you move all the other CODESYS processes (what CODESYS calls "IEC" tasks) to the same CPU core as the one running EtherCAT task?

I did not separate the other threads. If separated, there will be greater IEC task jitter when using other threads such as TCP and Codesys IDE communication, so they are all on the same CPU. Other threads account for about 20%. What determines this CPU load capacity? Is it determined by the A53 CPU?

It is not a problem to have 11 slave stations for 1ms. In Codesys, when checking the CPU load, full load mainly occurs when there are more slave stations, and full load always occurs and may even affect other threads on the same CPU

hao teng said:

If separated, there will be greater IEC task jitter when using other threads such as TCP and Codesys IDE communication, so they are all on the same CPU. Other threads account for about 20%. What determines this CPU load capacity? Is it determined by the A53 CPU?

It is not a problem to have 11 slave stations for 1ms. In Codesys, when checking the CPU load, full load mainly occurs when there are more slave stations, and full load always occurs and may even affect other threads on the same CPU

Have you contacted Codesys? It is commercial closed source SW and the details of how it measures things like CPU load are not something TI can answer. Generally in real-time once CPU load gets to 60-70% level it is the maximum performance you are going to get.