[ntp:questions] Refclock Oncore Driver Change

Terje Mathisen terje.mathisen at tmsw.no
Thu May 9 06:58:33 UTC 2019

Chris Adams wrote:
> Once upon a time, Terje Mathisen  <terje.mathisen at tmsw.no> said:
>> Having a known minimum date would be fine, the modification time of
>> ntp.conf could be used, or as you suggest, a new generic "epoch-start
>> yyyy-mm-dd" option in the conf file.
> I looked at the code before the GPS week roll-over, and there were a
> couple of places it was handled by comparing to the compilation date of
> ntpd (which seems a reasonable automatic check, since somebody using a
> 20-year-old copy of ntpd is probably not worth supporting).
> Ideally, this should all be standardized and handled in one place,
> rather than in each refclock driver.
Yes and no: Since wrap around can happen more or less anywhere depending 
upon the (input) time format used by that particular driver, only the 
driver knows what sort of increment to use. We also really don't want to 
introduce any new smaller limit on the range of dates NTPD can handle 
upon startup! I.e. approx. 10 years ago the startup code was modified to 
handle the full 32-bit range (+/- 68 years) instead of just 31 bits for 
half the range.

So the core code needs either a known variable (minimum_valid_time) 
which a driver can pick up, or an api which each driver can use to ask 
if "is_this_a_valid_time()" in a loop, incrementing the internal epoch 
number each time.


- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

More information about the questions mailing list