David Woolley wrote:
Jaiprabhu wrote:
Jaiprabhu wrote:
Assuming the following config:
[...]
restrict default kod nomodify notrap noquery
restrict 127.0.0.1
<<snip>>
Many thanks.
Anyone?
The thing I am most interested in resolving is, in which part of NTPd,
and how, can I determine that there are no valid peers left (either
they are unreachable or are not reliable servers) and therefore
determine the current global synchronization status to be "not-sync".
One of ideas I
Stratum = 16 - unsynchronised
Stratum = 1 through 15 synchronised.
You can do that with an ordinary client poll
Thanks Dave. One question though.
I have observed that the server reaches the reject state, while the
stratum stays the same (it was at 1), a long time after it moved into
the reject state. The server was moved to the reject state by making it
unreachable by adding it's IP in an iptables drop rule. The reject state
already means that the server is not a synchronization source. What's
the rule of thumb on the duration it would take for the stratum shifting
to 16?
You can also use the status flags provided by ntpdc's rv 0 command -
specifically read that variable if you write a custom program. A quick
check of the header files will tell you which bits are important.
Thanks. This looks like a good option. I'll give it a spin.
There is trap mechanism, but I don't know any details.
Note that synchronised is not the same as tightly locked. The error
can be ~128 ms with it still showing synchronised.
Got it.
<<snip>>
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
