Do you know how the ethercat control loop actually works?
Here is a slide deck from a presentation on Erhercat by Martin Rostan, the ETG president in Germany I went to when he was in Australia
vmnet.com.au:10003/d/s/13FfcZqiooYngfrLX...XlFwmcTS-l7mgkSOi5gw
Roughly, In the drive a target position and target velocity is updated by linuxcnc. The ethercat bus uses synchronized clocks to keep the slaves in sync and that Is synced to the Linuxcnc servo thread. Our linuxcnc driver (lcec) reads the bus at the beginning of the servo thread and written out at the end of the servo thread (the position of addfs in your hal file are important to achieve this lcec.read-all and lcec.write-all).
example hal:
github.com/rodw-au/linuxcnc-cia402/blob/main/cia402.hal
So Linuxcnc gets a chance to update slave parameters every servo thread cycle
The best analogy in the presentation is the high speed train and the slaves are a station. Packets can get on and off the train (Ethernet frame) as the packet passes through the station without the train stopping which is what our driver does in a single sevo thread loop via the order of the addfs.
Note that CNC is a small subset of Ethercat use as the majority of devices are deployed in factory automation. There are other field bus technologies mentioned in the PDF (and perhaps Mesa's hm2_eth driver that uses UDP) that compete but they are based on standard TCP/IP packets and while Ethercat uses the Ethercat frame directly (the carriage on the train). So Ethercat is much more efficient (lean) protocol so it performs better.
Interesting that competitors Profinet et al are sponsors of TSN (Time sensitive Networking) which is in a set of standard for Real time networking. They need it. Ethercat also supports it, but does not really need to due to is better efficiency. I'm not sure if the iGh Ethercat master we use supports TSN but it also requires TSN support on the NIC's on the slaves. That is another emerging story.
Hope I have not told too many lies here.