Re: [Linuxptp-devel] [PATCH] phc2sys: Add external time stamping support
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. It's not clear to me what exactly is this supposed to do. It requires the system clock to be specified as the source clock. Why? The only thing I managed to do with it is this: # ./phc2sys -e 0 -c /dev/ptp1 -s CLOCK_REALTIME -O 0 -m phc2sys[3070.094]: PPS is not in sync with PHC (0.940064462) phc2sys[3071.094]: PPS is not in sync with PHC (0.940014584) phc2sys[3072.094]: PPS is not in sync with PHC (0.940011248) phc2sys[3073.094]: PPS is not in sync with PHC (0.939944354) The patch needs to update the documention and explain what is synchronized to what in this mode. 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. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] phc2sys: Add external time stamping support
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. > > It's not clear to me what exactly is this supposed to do. It requires > the system clock to be specified as the source clock. Why? > > The only thing I managed to do with it is this: > # ./phc2sys -e 0 -c /dev/ptp1 -s CLOCK_REALTIME -O 0 -m > phc2sys[3070.094]: PPS is not in sync with PHC (0.940064462) > phc2sys[3071.094]: PPS is not in sync with PHC (0.940014584) > phc2sys[3072.094]: PPS is not in sync with PHC (0.940011248) > phc2sys[3073.094]: PPS is not in sync with PHC (0.939944354) > > The patch needs to update the documention and explain what is > synchronized to what in this mode. > > 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. > Hi Miroslav, I've been meaning to ask some clarification on this patch as well, and perhaps even ask for some suggestions. I believe the typical use case is to use a GNSS module as a clock provider. NMEA data would provide absolute time of day while the servo is unlocked, and PPS signal would provide phase alignment. The issue seems to be that there is no GNSS driver in Linux that exposes the time of day as a PHC. Aditionally, the PPS signal from the GNSS module usually needs to be processed by a PHC driver belonging to an Ethernet controller (and served to userspace as extts events). Frantisek Rysanek added the same functionality a while ago in a program called i210_ext_pps (https://sourceforge.net/p/linuxptp/mailman/message/36228042/) Unfortunately it suffered of the same limitation as the currently proposed patch does: it had no standard interface over which it could collect the GNSS module's time of day. -Vladimir ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] phc2sys: Add external time stamping support
Dear gentlemen, apologies if I'm completely off the mark in my response below, I'm not following the linuxptp internal developments and I don't quite understand the guts under the hood. Yet I feel like I could add some points, even if they're possibly void... for a start, this debate seems to be a little confused. Three people with different angles... 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? In that case, it doesn't make sense to me, what use this functionality is as part of the phc2sys program, as part of the linuxptp project. Again I'm not conversant with the workings of this project, so apologies for being so ignorant and opinionated - but the motivation to take timestamps for your own use, triggered by a GPIO, feels like a very generic application :-) and would probably deserve a "translation unit" (program name) of its own. Timestamping an external event input. Some Meinberg hardware has that function, for general purpose use = "give me a precise timestamp when I tug at this TTL input". Some people probably have a need for that feature, irrespective of linuxptp. > > It's not clear to me what exactly is this supposed to do. It requires > > the system clock to be specified as the source clock. Why? > > > > The only thing I managed to do with it is this: > > # ./phc2sys -e 0 -c /dev/ptp1 -s CLOCK_REALTIME -O 0 -m > > phc2sys[3070.094]: PPS is not in sync with PHC (0.940064462) > > phc2sys[3071.094]: PPS is not in sync with PHC (0.940014584) > > phc2sys[3072.094]: PPS is not in sync with PHC (0.940011248) > > phc2sys[3073.094]: PPS is not in sync with PHC (0.939944354) > > > > The patch needs to update the documention and explain what is > > synchronized to what in this mode. > > > > 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. So my proggie initially sets the PHC's Time of Day to system time (UTC) rather than TAI, and I'm not trying to keep an eye on leap seconds, and not trying to enslave the system time to the PPS-disciplined PHC - because the "attention span" of my capture sessions is a couple seconds to a couple days maybe. There's even a comment in my code, that remarks "you'd better discipline your system time using NTP or PTP or some such" - like I'm leaving that up to the sysadmin (=that is typically me on my machines :-) I really was interested in getting the precise ns-level PHC time in my captured packets (think t-shark). If memory serves, Richard Cochran's code snippet was aimed to build a primitive boundary clock. Its name is synbc.c . His code would use one PHC (PTP slave) as a PPS source and, using some discrete wiring, used its PPS output pin to drive some downstream PHC's (again via GPIO input) in the role of PTP masters. (So the first thing I did, I gutted that PTP slave PHC from the code :-) and went on from there.) > Hi Miroslav, > > I've been meaning to ask some clarification on this patch as well, and > perhaps even ask for some suggestions. > I believe the typical use case is to use a GNSS module as a clock > provider. NMEA data would provide absolute time of day while the servo > is unlocked, and PPS signal would provide phase alignment. > I do not think this is the motivation of the patch that started this mailinglist thread. But I'd also like to comment on your interesting point Vladimir: > The issue seems to be that there is no GNSS driver in Linux that exposes > the time of day as a PHC. Aditionally, the PPS signal from the GNSS > module usually needs to be processed by a PHC driver belonging to an > Ethernet controller (and served to userspace as extts events). > This sure is an interesting angle :-) You're right - the NIC's contain a PHC = effectively a timebase with some synthetic frequency adjustment capabilities, that can provide precise nanosecond-level timestamps be
Re: [Linuxptp-devel] [PATCH] phc2sys: Add external time stamping support
Hi Frantisek, Thank you for your work! I have to mention you on the mailing list. I found your paper "Hardware Assisted IEEE 1588 Clock Synchronization Under Linux", and there is similar work "Precision Time Protocol for Spectroscope Synchronization" from ZHAW university. I'm currently working on stratum-1 time server with GPSDO on board. The GPSDO driver exposes PHC interface, where timescale is TAI. We have two Synopsys NICs on board that have external timestamping support which are disciplined with GPSDO PHC clock. The results are accurate enough. I could share measurement results taken from Calnex Sentinel. I don't know how external timestamping support fits linuxptp project. It's very rare use-case, but I would like to have it in upstream. Thanks On Fri, 1 Feb 2019 at 23:27, Frantisek Rysanek wrote: > > Dear gentlemen, > > apologies if I'm completely off the mark in my response below, I'm > not following the linuxptp internal developments and I don't quite > understand the guts under the hood. Yet I feel like I could add some > points, even if they're possibly void... for a start, this debate > seems to be a little confused. > Three people with different angles... > > 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? > > In that case, it doesn't make sense to me, what use this > functionality is as part of the phc2sys program, as part of the > linuxptp project. Again I'm not conversant with the workings of this > project, so apologies for being so ignorant and opinionated - but the > motivation to take timestamps for your own use, triggered by a GPIO, > feels like a very generic application :-) and would probably deserve > a "translation unit" (program name) of its own. > > Timestamping an external event input. > Some Meinberg hardware has that function, for general purpose use > = "give me a precise timestamp when I tug at this TTL input". > Some people probably have a need for that feature, irrespective of > linuxptp. > > > > It's not clear to me what exactly is this supposed to do. It requires > > > the system clock to be specified as the source clock. Why? > > > > > > The only thing I managed to do with it is this: > > > # ./phc2sys -e 0 -c /dev/ptp1 -s CLOCK_REALTIME -O 0 -m > > > phc2sys[3070.094]: PPS is not in sync with PHC (0.940064462) > > > phc2sys[3071.094]: PPS is not in sync with PHC (0.940014584) > > > phc2sys[3072.094]: PPS is not in sync with PHC (0.940011248) > > > phc2sys[3073.094]: PPS is not in sync with PHC (0.939944354) > > > > > > The patch needs to update the documention and explain what is > > > synchronized to what in this mode. > > > > > > 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. > So my proggie initially sets the PHC's Time of Day to system time > (UTC) rather than TAI, and I'm not trying to keep an eye on leap > seconds, and not trying to enslave the system time to the > PPS-disciplined PHC - because the "attention span" of my capture > sessions is a couple seconds to a couple days maybe. > There's even a comment in my code, that remarks "you'd better > discipline your system time using NTP or PTP or some such" - like I'm > leaving that up to the sysadmin (=that is typically me on my machines > :-) I really was interested in getting the precise ns-level PHC time > in my captured packets (think t-shark). > > If memory serves, Richard Cochran's code snippet was aimed to build a > primitive boundary clock. Its name is synbc.c . His code would use > one PHC (PTP slave) as a PPS source and, using some discrete wiring, > used its PPS output pin to drive some downstream PHC's (again via > GPIO input) in the role of PTP masters. > (So the first thing I did, I gutted that PTP slave PHC from the code > :-) and went on from there.) > > > Hi Miroslav, > > > > I've been meaning to ask some
Re: [Linuxptp-devel] [PATCH] phc2sys: Add external time stamping support
On 2 Feb 2019 at 1:54, Artem Panfilov wrote: > Hi Frantisek, > Thank you for your work! I have to mention you on the mailing list. > > I found your paper "Hardware Assisted IEEE 1588 Clock Synchronization > Under Linux", and there is similar work "Precision Time Protocol for > Spectroscope Synchronization" from ZHAW university. > > I'm currently working on stratum-1 time server with GPSDO on board. > The GPSDO driver exposes PHC interface, where timescale is TAI. We > have two Synopsys NICs on board that have external timestamping > support which are disciplined with GPSDO PHC clock. The results are > accurate enough. I could share measurement results taken from Calnex > Sentinel. > > I don't know how external timestamping support fits linuxptp project. > It's very rare use-case, but I would like to have it in upstream. > Thanks Dear Artem, apologies for splashing water into your fireplace. Apart from me being irrelevant to linuxptp maintenance, personally I have nothing against having your hooks accepted into upstream code. (Per analogiam, thinking about how many odd things exist in the Linux kernel for instance...) The motivation for having things upstream is clear. Please note that I am not the author of "Hardware Assisted IEEE 1588 Clock Synchronization Under Linux" - that was written by Ferencz Balint, who's a proper academic researcher. I'm just a private tinkerer. His work predates my own attempts by several years. I have learned the crucial bits from his work. He's the pioneer, I am his humble apprentice. We are not the same person and we have never met. Frank ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] phc2sys: Add external time stamping support
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 Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] phc2sys: Add external time stamping support
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
Re: [Linuxptp-devel] [PATCH] phc2sys: Add external time stamping support
On Mon, Feb 04, 2019 at 11:31:01PM +, Vladimir Oltean wrote: > I don't see why letting userspace guess whether the extts event was > rising or falling is a good idea. Actually, years ago the user/kernel interface foresaw this distinction, and there are flags that were meant to be used for this. However, I didn't follow through and strictly implement these for the few drivers that support ancillary signals. Patches on the netdev mailing are most welcome! However, in the end, the API will surely never capture the actual complexity of time and measurement systems in a satisfactory, generic way. Witness the failure of APIs like Comedi (and certain commercial systems which shall rename nameless). Having said that, in practice this is not too hard to set up. For example, when using the i210, I simply configure a 1/2 Hertz periodic output, knowing well that the device generates time stamps on both edges, and that this cannot be re-programmed. I can only recommend this. Don't guess. Get to know your HW before deciding on the final design. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] phc2sys: Add external time stamping support
On Mon, Feb 04, 2019 at 11:31:01PM +, 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 Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] phc2sys: Add external time stamping support
...again just a few bystander opinions on my part: On 5 Feb 2019 at 9:37, Miroslav Lichvar wrote: > On Mon, Feb 04, 2019 at 11:31:01PM +, 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. > I believe that we should leave some responsibility to the admin :-) "Dear Admin: based on your configuration, you probably want to serve PTP with no upstream PTP source. You want to serve PTP using a NIC-based PHC disciplined by the PPS. Note that the PHC has no inherent notion of 'time of day' etc. We can initialize the PHC's wall time down to the second from the system clock, but THE RESPONSIBILITY IS YOURS to provide your Linux system clock with valid time, before you start the PTP service. Principally in theory, for a successful PHC initialization, your Linux system time should be accurate within < +/- 0.5s of the PPS edge that you provide to the PHC. Preferably much more accurate, for optimal results / safe PHC init." Note that low single-digit milliseconds of accuracy are possible with NTP off pool.ntp.org, i.e. using servers in the wild internet. There are so many different ways of providing plausible time to the Linux system clock... Let the admin pick one, using his best judgement - and let us take that "time reference" to initialize the PHC, and from there use the PPS input to servo the PHC. If the admin has an accurate PPS source that he can plug into our i210 PHC, does it even matter where the system clock's Time of Day information came from? Whether NTP from the wild internet, or incidentally that same GPS refclock providing the PPS ? On a decent timing GPS, the serial string alone is enough to get millisecond-level accuracy... And one more note specifically on: > > Who guarantees that [...] will not cause the NIC PHC to lean > > towards the wrong second, throwing its absolute value off by one? The algorithm in my proggie works in two steps: 1) ignoring the system clock or the absolute PHC time, just calculate the distance (nanoseconds) between the previous PPS event and the current PPS event. If the distance is short(-ish), probably the previous event was a leading edge and the current event is a trailing edge. We are interested in the leading edge, that's the whole-second boundary. (My algorithm actually looks for a particular expected pulse length +/- some margin, compile-time constants.) 2) now that we know the leading PPS edge, calculate its bipolar offset from the PHC's current whole-second boundary (which will be within +/- 0.5s) and start tuning the servo loop from there. Actually there should be a step 0) where the absolute PHC time is initialized by copy from the Linux system clock. So unless the system clock (used as initial reference) is off by more than 500 ms against the PPS edge used to discipline the PHC, the algorithm will converge to the correct second boundary. Simple quantisation math. If the system admin cannot get his act together, we can hardly decide this for him algorithmically (not having another reference to compare against). Though as Mr. Lichvar says, we could use an actual offset past some pedantic margin as a statistically probable indication that the admin has not done his homework :-) > A separate phc2sys instance can be used for monitoring the offset > between the system clock and PHC. > "just in case", I understand... to report errors into syslog, keep a watch in Nagios or something. Normally the deviation should not grow over time, if both the PHC and the system clock are disciplined, even if disciplined independently as we're suggesting here. > > 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. > isn'
