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 between PPS edges. And apparently the cascade of counters/dividers can also count seconds from epoch, POSIX style. As you correctly point out, the PHC's don't have an NMEA input. Or some such. I'd like to add that this was probably never intended. The NICs' timestamping PHC is likely geared for use in PTP. As PTP slaves in the first place. Would anyone want a bread-and-butter NIC to contain a GPS refclock driver? Just NMEA, or a plethora of other proprietary string formats as well? It would need a serial UART on chip, and some pins to waste, and the protocol is best crunched by an MCU running some code... Note that once you get the PPS input ticking, the PHC will keep counting seconds from the UNIX epoch straight on, forever. ...so... what would you need NMEA input *for* in the first place? Initialization of the PHC to the correct Time of Day = "seconds from epoch"? That's not a big problem, you can always initialize that part from the system time, if that's half decent. All you need is some other means of syncing the Time of Day. NTP gets you to millisecond precision over a modern WAN. NTP has refclock drivers for a number of proprietary radio clocks and string formats. 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. And then there are leap seconds. Does phc2sys know or care about leap seconds? NTP does get to know about them, from upstream NTP or from a radio refclock. But we need to shut down ntpd in the first place... Note that PTP is using the TAI as its time domain. So the PHC's actually can tick forever straight on, just counting seconds, oblivious of leap seconds. Leap seconds are transported as a data attribute in the PTP protocol. If you have NTP in the host system, then NTP disciplines the clock and tries its best to work around leap seconds. Nowadays with some support in the Linux kernel timebase, AFAIR. POSIX doesn't know about leap seconds, and NTP can use several different bad ways (pick your poison) to cope with them. PTP has its inherent TAI timebase and the UTC is derived using just a simple offset attribute (which accumulates any leap seconds over time). The question really is, how the PTP / phc2sys software stack in Linux gets to know about leap seconds and who's responsible for taking care of them. How about... configure ntpd to prefer the local system clock "pseudo-refclock driver" (which should disengage the system clock disciplining ambitions of ntpd), add one upstream NTP peer to get to know about leap seconds, and run phc2sys to discipline the system timebase from a PPS-based PHC? If all of this works, and ntpd gets to know about leap seconds, will it notify the Linux kernel timebase, while it's told not to tweak it? Will phc2sys get to know about leap seconds? Does it even care? Let's abstract from the leap seconds again for a bit. Forget leap seconds for now. So far the canonical use of linuxptp has been: - run ptp4l to turn a nic into a PTP slave = to speak the protocol, get to know about TAI/UTC offset etc. - run phc2sys to sync the system time base to that "PTP slave PHC" In that case, Miroslav's idea to just "add support for ext PPS" in phc2sys (or in ptp4l?) would be the low hanging fruit. Despite the fact that a PTP slave NIC is typically used as a PPS *source*, rather than a PPS input... now this sounds a little unconventional. What if we don't have ptp4l running? What if we don't have a PTP GM available? Would ptp4l let the slave PHC free-wheel forever, if there is no upsteam PTP GM? Would it be possible to e.g... start ptp4l in the GM role, on a particular NIC port, enable the ext.PPS on this "PTP GM NIC" (which would be the more typical place to enable ext.PPS) and then * run phc2sys against that PTP GM NIC PHC * ? Uhh... if I run ptp4l on a PC in a pure GM role, where does it take its time from? The system time base? Wouldn't that give rise to a funny feedback loop / chicken-and-egg race condition ? In my packet capturing lab machine I do have the system clock disciplined by ntpd or by ptp4l on a dedicated Ethernet port. I'm not running phc2sys to take time from the PPS-disciplined PHC's. External PPS is input to the PHC's dedicated to precise packet capture. (Accompanied by 25 MHz synthesized from GPS-based 10 MHz.) I'm ranting about things I know nothing about. I should probably read the code... except I don't have the time :-/ Apologies for my ignorance and thanks for your polite attention. Frank > 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
