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. 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. > 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. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
