mjjunk19 at gmail.com
Fri Aug 6 19:01:34 UTC 2010
David Woolley wrote:
> What do you mean by "resync with the local time"? The local time always
> has an offset of exactly zero so never affects the clock discipline,
> except possibly by diluting the effect of other sources.
Please forgive me. I'm an intern and pretty new to all of this, so my
terminology may be completely off. Let me try to clarify.
In 4.2.0, after ntpd receives from the broadcast server, ntpq -p will
return the following:
I can see that that ntpd is still polling the LOCAL clock, as the poll
is refreshing approximately every 16 seconds. Also, 'ntpq> as'
returns that LOCAL is rejected, but is still reachable.
If I kill the broadcast server intentionally (for testing purposes),
eventually (after about 6 minutes) ntpq -p will return:
So I assume ntpd is now using the LOCAL for the reference clock.
In 4.2.6p1, ntpq -p will return the same, except that it stops polling
the LOCAL clock, and 'ntpq> as' returns that LOCAL is both rejected
When I kill the broadcast server, eventually ntpq - p loses the BCAST
but never switches source to the LOCAL clock. ntpq -p returns the
Commenting out the aforementioned code causes 4.2.6p1 to behave in the
same way as 4.2.0.
> Does it report stratum 16, or the broadcast related stratum. If it
> reports the broadcast related stratum there is no problem; you are
> serving the local clock time indicating it is valid.
I'll have to look up how to check which stratum it's reporting.
> Root dispersion
> will continue to increase, to indicate that the time is suspect. The
> only reservation I would have is that it needs to switch source before
> the root dispersion gets to a point where clients will start ignoring
> it, but that should take about a day.
So even though ntpq -p does not show the * next to the LOCAL source,
will all the systems downstream still be served the time based on this
systems LOCAL clock? Which is really what I am after. I do not want
to modify source code if I do not have to.
> Incidentally, it seems weird to have a broadcast client that is not
> leaf node.
Again, my apologies, as I'm not familiar enough to understand what you
mean by leaf node.
I really do appreciate the input and help.
More information about the questions