Date: Sun, 02 Oct 2016 22:18:50 -0700 From: Paul Vixie <paul@redbarn.org> To: Victor Sudakov <vas@mpeks.tomsk.su> Cc: Peter Grehan <grehan@freebsd.org>, freebsd-virtualization@freebsd.org Subject: Re: Time sync Message-ID: <57F1EA3A.6070708@redbarn.org> In-Reply-To: <20161003044707.GA23918@admin.sibptus.transneft.ru> References: <20160922104303.GA33424@admin.sibptus.transneft.ru> <704d3b3c-887d-852b-aae9-6b26cad9eff0@freebsd.org> <20161003044707.GA23918@admin.sibptus.transneft.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
i would love to see a vclock driver so that the guest could reach up and grab the host's clock. running ntp on every guest feels silly. however, there's a problem with this, which i expect is the reason why it hasn't happened yet. ntp tries hard not to jump the clock, since when you do, there's a discontinuity visible to every process. time can march backward, periods can be skipped over, and most irritatingly, gettimeofday will return a tv_usec value greater than a million -- which many callers won't expect. presumably ts_nsec could be larger than a billion, too. ntp prefers to slew. that is, it makes the clock move always-forward but at a faster or slower rate as required to eventually make the time correct. ntp also drifts. if it learns after a while that its hardware clock is just slow or fast, it will change the rate at which the software clock marches forward, to minimize corrections (which would require slew). so while a "vclock" driver that allowed the guest to fetch the host's software clock value would be kind of useful, all of the slewing and drifting logic would still be nec'y, requiring either extra clock math in the guest kernel, or, more likely, running ntp after all. so i run ntpd on the guest and tell it that the host is its "master". note that 25 years after its birth, cron's understanding of time jumps including either "ntpdate" or daylight savings time, is horrible. but mostly the reason for this that there are often more than one answer, or no right answer. the best thing to do is run with a UTC timezone and never jump the clock when cron is running (noting, ntpdate runs before cron starts in the /etc/rc init systems i know about, and this is why.) vixie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57F1EA3A.6070708>