...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 +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. > 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't that in line with the UNIX way of doing things? :-) As for leap seconds, the Linux kernel has a flag that can be used either way for "advance warning" during the day before a leap second is scheduled. https://stackoverflow.com/questions/26202730 NTP daemons do use it, so does probably LinuxPTP, to give the kernel a hint about an upcoming leap second. If LinuxPTP runs in a "pure grandmaster" role, and has taken its initial wall time from the host system clock, LinuxPTP could use this flag to find out about an upcoming leap second, to update its TAI / UTC offset attribute. > > 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. > I guess I've scrutinized the i210 datasheet quite seriously (for other reasons - namely SGMII support) and I recall that my conclusion was fairly firm, that the i210 does not distinguish rising and falling edges on the external PPS input. BTW @Richar Cochran: > > > "just use 1/2 Hz 50% rectangle, don't guess": so that's why your code configures a 2-second period in the "upstream" PTP slave port, the one providing PPS output in your synbc.c . (You may have explained to me before, I don't remember.) This is only possible if you can configure your PPS signal. In GPS receivers this is hardly possible. You have to work with what the GPS vendor has implemented in his hardware. In my tinkering, I am lucky that Meinberg produce 200ms pulses, easy to process in software. The 5us pulses from Symmetricom could be tougher. I mean if I even know how broad the pulses should be, "guessing" is a fairly safe bet, a fairly good filter :-) As for seeing "just the rising PPS edges" from an i210: Not sure about the i210 external PPS, but e.g. the PC's legacy parallel/serial ports are no good at sensing PPS from sources that use a very narrow "duty cycle" (pulse width) - such as refclocks that provide a 5us PPS. This is too short for the old circuitry to process. Maybe the i210 also has some "debouncer" on the external PPS input? If this is implemented by masking further events coming too soon, and the first trigger is actually accepted, that would be an explanation. I have found no references to such debouncing / filtering in the i210 datasheet. As for "where the detection of leading vs. trailing PPS edge should be done, kernel or user space" or "this should be the task of the PHC driver": Looking at the code of my proggie (or Mr. Cochran's prior art), I believe that the API works with events, rather than specifically PPS. Also the hardware functionality that we're using for PPS input is apparently technically a feature that takes a PHC timestamp on an external event - and the user space program acts upon the event (servoes the PHC's clock frequency). The PHC driver's feature that we're using is general event timestamping, not the semantically more specific PPS. So unless the relevant maintainers extend the timestamping API somehow (or the PHC API) to explicitly give a PPS edge event, it probably doesn't make sense to scowl the driver that it does not distill the leading edge on hardware that unfortunately doesn't differentiate between rising and falling edges on its GPIO input (and the driver does not know or care about the special temporal properties of PPS, to him the pin is just a misc event-triggering GPIO). And yes it is unfortunate that Intel implemented the SDP pins' event triggering in this ambiguous way - OTOH, thanks nonetheless that it exists at all :-) As it only happens once (well twice) a second, and it's the timestamp's accuracy that matters, rather than processing delays, I don't feel particularly offended if the servo loop runs in user space software, using the generic events API. The timestamp accuracy is assured by taking the timestamp in NIC/PHC hardware. Yes it would certainly be cool if the servo loop ran in a kthread :-) belonging to the PHC driver. Frank Rysanek _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
