What is the mechanism of compensation-jitter or handling jitter in linuxcnc??

Hello, LinuxCNC

I have some question about compensating jitter in linuxcnc. 

Maybe I guess there is DC(distributed clocks), but I don't know the mechanism.

I think there are some codes that let slaves know amount of jitter(?_or size of jitter?) occured or that says to slaves "hey I'm late about 10us"  in linuxcnc-ethercat master source code,

when call the jitter-compensation-function in linuxcnc-master, linux-cnc-master and ethercat-master???

How to compensate jitter in linuxcnc??? 

Plz let me know!! 
 

EtherCAT in general handles most of this for us. Run `ethercat slaves -v`, and one of the fields provided should show the measured latency from slave to slave and overall. It tends to run around ~200 ns per hop. Distributed Clocks should help keep all of the slaves' clocks in sync within a small number of microseconds, but I don't have the spec for that in front of me.

I don't think we have anything today that explicitly checks that jitter is low, other than the usual servo time checks, but I may be mistaken. I haven't dug into that bit of the code very deeply.

I don't think linuxcnc cares about jitter as long as the Servo-thread ( usually 1 kHz) is not overrun. In some kernel traces we did, the servo thread was executed in about 200 usec and slept for the remaining 800 usec. The thread does not run late until the execution time exceeds 1000 usec.
Ethercat has its own synchronisation method, but its not something we care about.
Ethercat is a very efficient communication protocol and the time it takes is a lot less than normal  TCP networking used by say a Mesa Card so it is more immune to timing overruns due to latency.

Pretty sure i read somewhere Mesa cards use TCP just for the initial comms, then UDP, can anyone confirm this?
Sorry, on the phone.

whether its tcp or udp, it does not matter, ethercat is more efficient due to both shorter packet length and less overhead in the packet. I did look at the hm2_eth code once and from memory it uses sockets. Once a connection is negotiated, it would make sense to use UDP. But there is still handshaking happening. With ethercat, the packet is unloaded by the relevant slave on the fly as the train goes past the station without stopping.

I have attached a paper on this from a seminar I attended.
It also deals with the distributed timing mechanism used by ethercat.

Oops too big, try this
drive.google.com/file/d/19VggxoJGlKLrIm4...H2M/view?usp=sharing

 

With UDP there is no handshaking going on. Ethercat is faster chiefly because it
has it own real time hardware Ethernet driver and uses a single packet for
all communication.The packet overhead (unused data) is negligible in either case.
hm2_eth uses three packets, an outgoing read request, an incoming read data packet and then
an outgoing write data packet. These are the main differences. Note that to match
LinuxCNCs read inputs, process input data ,write outputs mode, Ethercat would need
2 cycles per servo thread.

Hostmot2 deals with jitter by using a DPLL the locks onto the servo
thread and can reduce critical sampling times to the 100s of ns region.
EtherCAT has a couple similar mechanisms (distributed clocks etc)