Enable custom rtc clock source
Solves #23
The question for me is whether the following line also needs to be adapted to the custom CLOCK_SOURCE. https://github.com/robert-burger/libethercat/blob/9108db144f028f763203957c595d9b39bc04505e/src/dc.c#L354
The packet latency in
https://github.com/robert-burger/libethercat/blob/9108db144f028f763203957c595d9b39bc04505e/src/dc.c#L100-L108
also uses osal_timer_gettime_nsec(). In libosal for POSIX, CLOCK_REALTIME is currently used, which I think is not optimal, because it can be changed by NTP (see here). So, at least for Linux CLOCK_MONOTONIC is better.
For measuring packet latency it doesn't matter which time reference is used, but for DC sync it is important if you want to synchronize the master rtc to an external clock, e.g. via PTP. In this case, you would prefer CLOCK_TAI.
Hi Marc,
i know that CLOCK_REALTIME is affected by NTP (i think our realtime system do not use NTP) so switching to a different clock source is a good option here.
But despite modifying/hacking this into libethercat wouldn't it be better to make it configurable in libosal to support CLOCK_MONOTIC(_RAW) and CLOCK_TAI? Then we do not need to take care about where a different clock source might be used here.
Cheers Robert
Hi Robert,
Making the libosal configurable sounds good. I can make a suggestion.
Just a question about the ec_send_distributed_clocks. When using SO_TXTIME, you use the send() call before the actual send time to queue the frames in the ethernet adapter with a txtime. The adapter will then send the frames at the specified time. So I think ec_send_distributed_clocks should use the specified txtime, right?
is this still necessary although we changed clock source in libosal?
Rebased and ready