Lose the per-driver PPS code
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.
This issue is currently on-hold - we need more discussion about this point.
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?
- 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.
- 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).
- 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
- 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.
- 25 Mar 2007