[Linuxptp-users] UtcOffset (leap seconds)

[Keller, J. E <jac...@in...>]

I recently had ptp4l running with a symmetricom grandmaster Xli box which I am using as an interop test for ptp4l. I noticed something odd, when configuring the setup. The grandmaster clock can be in a "master only, no slave" mode or a "slave only, no master" mode. When in slave only mode, it causes ptp4l to automatically fall back to master setup.

The ptp4l state machine then never runs the best master clock routine, and so it never sets up the UtcOffset value in the announce field. This causes the grand master clock to use the previously known utc offset which in this case is 34 seconds. This causes a delay of 34 seconds in the clocks. I discovered that the clock property fields only get set when in the grand master state, which it will *never* enter because it doesn't properly run the best master clock algorithm. (Since in this case there is no other announcer).

I am not sure what the correct answer to this question should be. Under normal circumstances with other ptp4ls, the utc offset is ignored. This particular clock, though, cannot have the utc offset changed to something outside the -19/-40 range, so I cannot manually reset the offset to 0.

Is it correct to not properly configure the ptp4l clock when it is in fallback mode, or should it be changed to update the clock settings when it goes to master mode as a fallback? Normally the clock would go to grandmaster mode because there are no other clocks on the network with higher priority.. But it never does this in fallback mode, because it never receives an announce message at all.

Thanks


-          Jake