On 11/21/2012 06:58 AM, Magnus Danielson wrote:
It was a common mode error to both servers. It's worth nothing that even a high-ranked clock house like USNO can have these errors so trusting the one and true server can fail greatly. NTP by it's design has methods to handle these kind of errors given sufficient many refences, where as for example PTP always trust its server. If USNO would have had multiple (different) time-links to their servers they could have potentially mittigated this before it hit the server time.
Unfortunately, default timekeeping on windows seems to be of the simple variety, where it sets the clock once a day from a single sample. It's really problematic considering Active Directory depends greatly on time synchronization to do its job -- I saw reports of domain controllers applying that time change to the year 2000 and needing to be restored from backup. I've seen some documentation that suggests that there is NTP-like functionality built into the server editions at least, but having looked at a build server whose clock was a few minutes off I see no such thing. Third-party NTP builds such as meinberg's of course get the job done with no fuss.
You're right though that anyone impacted by this has configuration problems to solve, even USNO servers are not to be fully trusted.
_______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
