On Mon, Feb 04, 2019 at 11:31:01PM +0000, Vladimir Oltean wrote: > On 2/4/19 2:53 PM, Miroslav Lichvar wrote: > > I was thinking about a similar approach. I'm not suggesting to use a > > second time source (e.g. a GNSS refclock) to pair the pulses with real > > time, only to synchronize the PHC to the nearest second using the PPS > > input. The PHC can be initially set by ptp4l from the network, by > > phc2sys from the system clock, or something else from the refclock. > > Then phc2sys using the PPS input can take over and keep it > > synchronized to TAI (no leap seconds). ptp4l can work as a grandmaster > > on the PHC. That is my use case. > > Who guarantees that the switchover time between the states "1. NTP GNSS > refclock driver disciplines system clock", "2. NIC PHC takes a sip of > system time for initial time of day" and "3. PHC keeps chugging along > keeping time of day based on PPS only" will not cause the NIC PHC to > lean towards the wrong second, throwing its absolute value off by one?
phc2sys can require the clock to be very close to the pulse edge, e.g. 10 milliseconds, and refuse to operate when the offset is larger. We can make some assumptions about maximum frequency error of the clock (e.g. 500 ppm) and calculate the maximum time for phc2sys to lock. A separate phc2sys instance can be used for monitoring the offset between the system clock and PHC. > And why pass GPS -> NIC PHC disciplining through the system time at all? I think that would be the easiest approach using the existing tools. But it's not a requirement and phc2sys shouldn't care about that. If you had a program that can timestamp serial data using the PHC, you could avoid the system clock completely. > Currently in core PTP kernel framework there is no way to distinguish > between rising edge and falling edge extts FIFO events. That being said, > the only sane options I see are (a) patch drivers to only report rising > edge (b) make the distinction at the level of individual extts FIFO entries. > I don't see why letting userspace guess whether the extts event was > rising or falling is a good idea. If the HW could report what edge it is, or could be configured to report only rising or falling edges, that would be great. I don't remember seeing a way to do that in the I210 datasheet. But what's strange is that I saw in one case with an I210 that it was reporting only the rising edge. I'm not sure if there was a problem with the PPS signal, or I accidentally put it in some weird state. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
