LoseThePerDriverPPSCode < Dev

---+ 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.

<div style="float:left;padding-right:1em">
| *What*  | *Status*  |
| Master | %BUG{557}% |
| arbiter | (seems OK) |
| as2201 | (seems OK) |
| hpgps | (seems OK) |
| jupiter | %BUG{560}% |
| msfees | %BUG{561}% |
| mx4200 | %BUG{562}% |
| nmea | %BUG{563}% |
| oncore | %BUG{559}% |
| parse | %BUG{558}% |
| ripencc | %BUG{564}% |
| trak | %BUG{565}% |
| true | %BUG{566}% |
| zyfer | %BUG{567}% |
</div>
---
---

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

-- Users.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.

-- Users.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).

-- Users.FrankKardel - 01 Feb 2006

---
This topic: Dev > WebHome > LoseThePerDriverPPSCode
Topic revision: r5 - 2006-02-01 - 13:38:05 - SteveKostecke