Rob wrote:
Kalle Pokki <[email protected]> wrote:
Yes, but reference clock drivers don't use the ntp timestamp. Take a
look at e.g. the SHM driver. There
Is this piece of code something that our friend does not want to change
because he believes it is doing the right thing? Or is it merely badly
written by a contributor and nobody got around to cleaning it up?
I would say it is completely pointless to decompose a timeval timestamp
into separate fields and then back. That only costs CPU time and induces
errors.
You should read the discussion in the bug report that was previously
provided by Kalle: https://bugs.ntp.org/417
It includes justification from David Mills on why it works this way. I
don't know that his justification specifically addressed the inability
to even force a quick sync with a refclock when it differs by more than
4 hours from system time (i.e. the CLOSETIME stuff). To me, there is no
justification for such behavior with respect to forcing a quick sync.
In such cases, ntpd is saying to the user "I know best" but it turns
that it doesn't.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
