On Fri, Sep 22, 2017 at 4:32 AM, Miroslav Lichvar <mlich...@redhat.com> wrote: > Is the PHC synchronized by ptp4l? You could use phc2sys -E ntpshm to > get the reference time in UTC in a SHM segment and use that in chrony > with the SHM refclock instead. > > An advantage of this approach is that chronyd will stop accumulating > new samples when the PHC is no longer synchronized as phc2sys is > continuously checking state of the PTP port.
Yes, the PHC is synchronized by ptp4l. I had originally set things up using phc2sys (using timemaster, similar to your blog post at [1]), but removed it from the equation when I saw some weird behavior. When I was using phc2sys, I would observe that when left running for a long period of time (not very long, like 24h would be sufficient), chrony's reported offsets, and root dispersion would go crazy for a while and then come back into line (they would go crazy for a few hours or so). I happened to observe one of these episodes in real time and restarted phc2sys, which immediately caused the issues to stop. I figured perhaps it was some kind of feedback loop between phc2sys and chrony. Its possible I had phc2sys misconfigured, but, I was using timemaster, so I'm not sure how I would have managed that. When I realized that I could point chrony at the PHC directly, I decided to just remove phc2sys from the equation and stopped looking as that seemed to give me stable results. I didn't realize that phc2sys was checking the state of the port, that is an interesting thing to consider. We also have monitoring that is checking various aspects of ptp4l (including the state of the port), so our monitoring would report any issues with ptp4l as well, but the idea that chrony wouldn't accumulate the samples is interesting. > Another possibility is to configure the PHC refclock with the pps > option, so it would use only the sub-second offset. This assumes an > additional source (NTP server or non-PPS refclock) is available. I had been looking at this as well. I'll have to think about this a bit harder and test it out. > I think a new "tai" option could be added for refclocks. If specified, > the refclock code would call something like REF_GetTaiOffset() and add > (or substract?) the value to offset in all samples. In my particular case (assuming I don't ultimately wind up using one of the alternatives you proposed), that would be very helpful. What would you imagine the time frame to get something like that going would be? I'm not trying to ask you to do it now, just curious when it might land or if attempting to provide patches for such a thing would be worthwhile. [1] http://rhelblog.redhat.com/2016/07/20/combining-ptp-with-ntp-to-get-the-best-of-both-worlds/ -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
