ntpd claims stratum 1 on start, while still unsync

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ntpd claims stratum 1 on start, while still unsync

Florin Vancea
Hello and good day.

Unessential intro:
My NTP systems are intentionally restricted from mailing out so I am posting the bug on the email
address instead of using sendbug.
And I'm new to BSD world, even though I have more than a bit of experience with Linux and stuff.
I also did not find a bug reporting mechanism on OpenNTPD (except of the portable part, which is not
what I have here).

*** Actual Problem ***
I have found out (by merely watching "ntpctl -sa" on server and on client) that ntpd (wrongly)
claims to be stratum 1 right after starting, during the period when it is unsynchronized.
It appears that it does serve NTP at some point during that unsync interval and it claims to be
stratum 1. This misleads downstream clients to pick it as favorite and assign a long refresh
interval to it.

My configuration is OpenBSD 6.7, recently upgraded from initial install of 6.6.
Syspatch returns immediately without any action so I suppose it is running the latest versions.

I suppose the above description is enough for someone who knows the inside of the OpenNTPD to
identify the problem (if there is one).
I think the server should return a very low stratum if unsync or maybe it should reject entirely any
request unless it is sync and stable (at which time it should report a proper stratum).

If additional detail is needed, I can try to add a cleaner cut with captured commands output.

Or if nobody more able than me will pick this, maybe I'll push my coding abilities to the challenge,
read the source and suggest directly a patch.

Thank you for caring,
Florin



Reply | Threaded
Open this post in threaded view
|

Re: ntpd claims stratum 1 on start, while still unsync

Florin Vancea
Hello again and apologies for jumping the gun a bit.

After additional testing I found out that the server does indeed respond to clients before ntpctl
reports sync and stratum.
It does not claim stratum 1 (as I wrote in the message subject) but a stratum which is visible to
ntpctl -sa only after a while.
Explanation to my confusion: In my original message I suppose the vmt0 was not yet disabled and the
server thought it was stratum 1.

However, something remains:
Maybe treating vmt0 as a true GPS-like reference is the actual problem here and this should at least
be mentioned somewhere in the docs.
The clock from the VMware host is nowhere like a GPS reference and using it as reference should not
make the ntpd instance advertise itself like stratum 1.

Again, thank you for caring,
Florin

> -----Original Message-----
> From: Florin Vancea [mailto:[hidden email]]
> Sent: 27 mai 2020 17:03
> To: '[hidden email]'
> Subject: ntpd claims stratum 1 on start, while still unsync
>
> Hello and good day.
>
> Unessential intro:
> My NTP systems are intentionally restricted from mailing out so I am posting the bug on the email
> address instead of using sendbug.
> And I'm new to BSD world, even though I have more than a bit of experience with Linux and stuff.
> I also did not find a bug reporting mechanism on OpenNTPD (except of the portable part, which is
not
> what I have here).
>
> *** Actual Problem ***
> I have found out (by merely watching "ntpctl -sa" on server and on client) that ntpd (wrongly)
claims
> to be stratum 1 right after starting, during the period when it is unsynchronized.
> It appears that it does serve NTP at some point during that unsync interval and it claims to be
stratum
> 1. This misleads downstream clients to pick it as favorite and assign a long refresh interval to
it.
>
> My configuration is OpenBSD 6.7, recently upgraded from initial install of 6.6.
> Syspatch returns immediately without any action so I suppose it is running the latest versions.
>
> I suppose the above description is enough for someone who knows the inside of the OpenNTPD to
> identify the problem (if there is one).
> I think the server should return a very low stratum if unsync or maybe it should reject entirely
any
> request unless it is sync and stable (at which time it should report a proper stratum).
>
> If additional detail is needed, I can try to add a cleaner cut with captured commands output.
>
> Or if nobody more able than me will pick this, maybe I'll push my coding abilities to the
challenge, read
> the source and suggest directly a patch.
>
> Thank you for caring,
> Florin