On 2/4/19 2:53 PM, Miroslav Lichvar wrote: > On Fri, Feb 01, 2019 at 09:10:36PM +0100, Frantisek Rysanek wrote: >> On 1 Feb 2019 at 17:42, Vladimir Oltean wrote: >>> On 01.02.2019 16:25, Miroslav Lichvar wrote: >>>> On Fri, Jan 18, 2019 at 03:50:51PM +0300, Artem Panfilov wrote: >>>>> The auxiliary snapshot feature allows you to store a snapshot >>>>> (timestamp) of the system time based on an external event. >>>>> This feature is supported on Intel and Synopsys GMAC NICs. >>>>> 1PPS signal could be connected as external timestamping source >>>>> and used to estimate error. >>>> >> >> I believe we should take this description at face value. >> Seems to me that the "aux event input" of the Intel NIC is used as a >> mere GPIO, used to trigger the taking of a timestamp, where the >> reference is the system time for some reason, rather than the NIC's >> very PHC... do I understand this correctly? > > The NIC doesn't (shouldn't?) know anything about the system time. I > think in this case it may be the NIC's "system time" as referred to by > the HW documentation, but that doesn't explain why the patch requires > CLOCK_REALTIME. > >>>> What I'd like to see implemented, and I'm not sure if that's what this >>>> patch is trying to do, is synchronization of a PHC to its own PPS >>>> input. When the PHC is synchronized to an external PPS signal, the >>>> system clock could be synchronized to the PHC. >>>> >> That sounds pretty simple to achieve, right? On top of what phc2sys >> already does... >> >> I believe I do a bit of that in my proggie. But I have an irrelevant >> motivation: packet capture with precise timestamping, rather than >> PTP. > > 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? And why pass GPS -> NIC PHC disciplining through the system time at all? Correct me if I'm wrong, but GPS time base and TAI are off by exactly 19 seconds from one another. All the UTC / leap second complications that Frank aptly pointed out arise just because we introduce the system time as part of this equation. IMO the separation of concerns is arbitrary at "GNSS time of day belongs to ntpd to discipline system clock (and NIC PHC, indirectly)" and "GNSS PPS output belongs to phc2sys / i210_ext_pps to discipline NIC PHC PPS input". Maybe it would help to see some comments on how this is dealt with in real life in a grandmaster system. Granted, I have zero familiarity with NTP and so little with PTP. If the PTP grandmaster time-of-day problem is long solved in the NTP camp, I apologize in advance and will quietly return to the horn-book. > > The point is that in this mode there still should be only one time > source. No assumptions about the system time. > > phc2sys doesn't support multiple time sources as that's not needed in > PTP. I'm not sure if anyone would be interested in extending phc2sys > in that direction. I think that's more a domain of NTP > implementations, which are required to work with multiple sources. > > There is also an issue that both rising and falling edges may be > reported by the HW/driver (e.g. I210) for each pulse, so phc2sys > should be able to filter the edges. 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. Other than that, I must say I've been quite successfully using a trivially patched version of Frank's i210_ext_pps program paired with the Freescale/NXP qoriq_ptp driver. In that case, the hardware only emits rising edge events, so edge detection code was simply removed. > >> But wait: there's a chicken-and-egg problem. >> To discipline your Linux system timebase from a NIC PHC, >> you first need to turn ntpd off. >> So you'd need to first run ntpd or chrony for a while, or take a sip >> of NTP using ntpdate, and only then start phc2sys. > > chrony actually supports the external PPS timestamping on a NIC, and > it can be combined with a refclock (gpsd, or ntpd driver), but it > doesn't synchronize the PHC itself. It synchronizes only the system > clock, which means it's not possible to run ptp4l on the PHC. Running > phc2sys to synchronize the PHC to the system clock while chrony is > running probably wouldn't work very well. It would be better to add > support for PHC synchronization. > >> And then there are leap seconds. >> Does phc2sys know or care about leap seconds? > > Only when it's synchronizing the system clock to a PHC synchronized by > ptp4l. > _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
