Its possible that your network routers or other hardware might provide NTP service, so that could be an option, assuming they are actually synced to something correctly.
Also, NTP can operate in peer mode where they all sync with each other, so if any one or a few get wildly out of sync, they will be brought back in line with the others. That doesn't mean they would all be correct, but they would all be the same amount of wrong. That's probably a better option in the event that all external sources are lost. ❧ Brian Mathis @orev On Tue, Nov 25, 2014 at 5:49 PM, Mathew Snyder <[email protected]> wrote: > I agree for the most part. However, in the past we've seen time drift > significantly when running ntpd and syncing to VM-hosted NTP servers. This > is where my concerns stem from. > > Any VM solution we implement will run RHEL6 and sync to the USNO. > Resiliency will be built in a far as we are able. After all, if external > network communication is lost we won't have a hardware clock to keep things > somewhat in line. > > On Tue, Nov 25, 2014, 07:23 Tom Perrine <[email protected]> wrote: > >> What I'm seeing is that for the purposes of NTP, you should pretty >> much treat a virtual host the same as a physical host. This seems to >> have changed from the olden days of VMware when you locked the >> underlying physical server with NTP, then had the guests just trust >> the presented clock as ground truth. This is new to me, and very >> welcome. VMware vs. clock fights were always a royal pain. I'm glad >> those are gone. >> >> But in terms of time references, these days, I don't see much reason >> to run my own primary clock, to be honest. The public pools are of >> high enough quality that they should probably be considered a primary >> reference for most peoples' purposes. >> >> For 99% of the folks I've talked to over the years, the most important >> thing about their time reference is that everything they control stay >> sync'ed. Few of them have really truly cared if their entire >> infrastructure was <1 millisecond off from the rest of the world. >> >> The important thing is that their entire infrastructure slew together >> if anything slews at all. As long as all your stuff stays synced, you >> get the benefits that you're likely looking for: trustable timestamps >> in logs, AD/Kerberos auth works, file timestamps are comparable across >> all your systems, etc. >> >> For that, building your own stratum of NTP servers that are based on >> the public pools are fine, then sync everything off your own "top >> level" stratum. >> >> The farther you are from the "one true global top-level stratum", the >> farther you might be from "atomic clock time", but everything that's >> locked to your own internal top-level stratum should slew together, if >> it slews at all. >> >> >> >> >> >> >> On Mon, Nov 24, 2014 at 1:59 PM, Brandon Allbery <[email protected]> >> wrote: >> > On Mon, Nov 24, 2014 at 4:44 PM, Alexander Lobodzinski >> > <[email protected]> wrote: >> >> >> >> Of course NTP soon gets a grip >> >> on it but resynchronization takes some minutes >> > >> > >> > Try "burst" instead of "iburst". >> > >> > -- >> > brandon s allbery kf8nh sine nomine >> associates >> > [email protected] >> [email protected] >> > unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > >> > _______________________________________________ >> > Tech mailing list >> > [email protected] >> > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech >> > This list provided by the League of Professional System Administrators >> > http://lopsa.org/ >> > >> _______________________________________________ >> Tech mailing list >> [email protected] >> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech >> This list provided by the League of Professional System Administrators >> http://lopsa.org/ >> > > _______________________________________________ > Tech mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ > >
_______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
