Lose the per-driver PPS code

What Status
Master NTP-BUG 557
arbiter (seems OK)
as2201 (seems OK)
hpgps (seems OK)
jupiter NTP-BUG 560
msfees NTP-BUG 561
mx4200 NTP-BUG 562
nmea NTP-BUG 563
oncore NTP-BUG 559
parse NTP-BUG 558
ripencc NTP-BUG 564
trak NTP-BUG 565
true NTP-BUG 566
zyfer NTP-BUG 567

Dave wants to lose the per-driver PPS code and let the ATOM driver handle it all.

Let's use this topic to discuss issues about this set of bugs.

ALERT! This issue is currently on-hold - we need more discussion about this point.

IDEA! The original topic name (LoseThePer-driverPPSCode) was not a WikiName (which interferes with the automatic link creation). I've moved the content here and changed the original topic to be a redirect. -- SteveKostecke

Harlan: Do the remarks "seems OK" mean - OK as they do not use any of the PPSAPI?

-- FrankKardel - 01 Feb 2006

Yes, it means that I did a grep PPS refclock*.c and the ones marked "seems OK" only discussed PPS in their comments.

-- HarlanStenn - 01 Feb 2006

The thing is that the refclock drivers know exactly whether the PPS of the device they are controlling is valid by the information from the device itself.

ATOM/PPS must use PPS derived time stamps only when the clock is doing well. ATOM/PPS has currently no way whatsoever to know about the health state of PPS (I currently see a 500ppm frequency check) - it assumes that PPS is always valid when it is there.

We have seen refclock/network scenarios where knowing whether PPS is healthy was absolutely crucial (effect: oscillating clock setting of several 100ms).

The scenario was invalid PPS information from a PPS source and valid time time information from the network.

For ATOM/PPS we would need an interface where the PPS health information is available to ATOM/PPS.

Currently this task is managed in the refclock drivers (some better, some worse).

-- FrankKardel - 01 Feb 2006

It would be nice to have ntpq display the appropriate peer tally code depending on the health of PPS for ATOMized drivers

-- SteveKostecke - 01 FEb 2006

I would like to chime in here, and say that I disargee 100% with Dave on this.

The nature and properties of the GPS signal are only know to the relevant refclock driver, and instead of evicting all the PPS handling to the ATOM driver, we should create an API which the refclocks can use to get PPS-API (or other APIs as relevant) service for a given filedescriptor.

One very clear example of why involving the ATOM driver is the wrong way to go is the oncore refclock. The oncore transmits T-RAIM status, estimated error, necessary corrections and other PPS contextual information in the serial data stream, and instead of giving the ATOM driver an unwieldy interface for generalizing these data, it would be simpler for to give the refclock_oncore the timestamps and implement the necessary corrections and policies in the refclock where the necessary information is already present.

I will also add, that in my "NTPns" implementation, this is in place and working, so anybody claiming that this is "impossible" or "unpractical" has a bit of uphill argument in front of them.

-- PoulHenningKamp - 25 Mar 2007
Topic revision: r8 - 25 Mar 2007, PoulHenningKamp
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Network Time Foundation's NTP Support Wiki? Send feedback