From owner-freebsd-virtualization@freebsd.org Mon Oct 3 05:19:02 2016 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF6D6AF349F for ; Mon, 3 Oct 2016 05:19:02 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF9191DA; Mon, 3 Oct 2016 05:19:02 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from [192.168.4.95] (unknown [81.89.213.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C94F43AF59; Mon, 3 Oct 2016 05:18:53 +0000 (UTC) Message-ID: <57F1EA3A.6070708@redbarn.org> Date: Sun, 02 Oct 2016 22:18:50 -0700 From: Paul Vixie User-Agent: Postbox 5.0.2 (Windows/20160922) MIME-Version: 1.0 To: Victor Sudakov CC: Peter Grehan , freebsd-virtualization@freebsd.org Subject: Re: Time sync References: <20160922104303.GA33424@admin.sibptus.transneft.ru> <704d3b3c-887d-852b-aae9-6b26cad9eff0@freebsd.org> <20161003044707.GA23918@admin.sibptus.transneft.ru> In-Reply-To: <20161003044707.GA23918@admin.sibptus.transneft.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 05:19:03 -0000 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