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:fvan...@maxiq.ro] > Sent: 27 mai 2020 17:03 > To: 'bugs@openbsd.org' > 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
