On 11/21/2012 04:11 PM, Michael Tharp wrote:
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.
As already discussed in a previous thread, that is SNTP and it is an
unsupported feature. SNTP is not the full NTP by any means, so when I
write NTP I mean the full NTPv4 functionality.
Third-party NTP builds such as meinberg's of course get
the job done with no fuss.
Which is in the list of minimum things to do, as well as ensuring a
sufficient set of servers is being used.
You're right though that anyone impacted by this has configuration
problems to solve, even USNO servers are not to be fully trusted.
It only shows that you get the timing you deserve, the toolbox is there
and many servers is available.
Cheers,
Magnus
_______________________________________________
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.
