Chris Adams wrote:
Once upon a time, Terje Mathisen <terje.mathi...@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
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
