[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

statistical time calibration


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 18 Jan 2022 16:03:56 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=v71U7bKeX34bVzkLSSSx/pXCeCSUsgtz4pi0lrhww9U=; b=GwBXh+Vp5aZftHUPWBDH+SnTvPfEVlqePpd/yStlIm7ntg5SHTdDkiezNRnAuxRCiQjOjSPWpYWzSIuSFA44x2cwAJSXMq5dll0LpMoD8I66PCdmGjgaYDChFs0e7Fr8O09Dl/NvtbvvRlfTgblV5gzs4FZksLnBl0VasYvhr8eWwRXrsci8psQ66nWAH0WxFjZiRecFHorxSjMnIqWkX4PEJydibC46AA6KBVLmNnX5hpQGg+QWOHHJSXdD0maoIz/cRNaGIB3c2FjhrpKCjxFcGRbksl8Ehj/cZE0IHsTwuOAJCb0HbHATwKYJdQxvvMgP2LCurxOEQP5PqIi+uQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jVgyraamcb/eoMvaGOVA41A+FuW0ETxmcp2l9tNs295SZI721ZHS0541xbQjzf8ECOWJNSlVgwl/2ijf5ItvcNQS9vILBVuvJcESUTWnJqYxVamhfdfRy0XBIU4Fx40Zt3gUSC8H09QADL9msZld0e6Rxoxx4UPa6Z35ongGyQOuPow3cXSz80DLOclrn0kxJwZ4Lc2WrKzCuKE5f0N+KUCyU0jzfVkW8+QsuYReqM/sygVhaWKU3EYzx78k2tGpu82XJqtLi4amr1iwhnv2Vx8Kv/RV13KvWMbSxY5jh+9XQ12OjxKtULst0RhNlNj9BPec26oWtvC7b/SsWzewIQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Tue, 18 Jan 2022 15:04:20 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hello,

Roger pointer me to a FreeBSD commit [1] introducing such there. While
we don't start at 2000ms (but rather at 50), this still looked interesting
enough to take a closer look. I think I've mostly understood the idea and
implementation now, with the exception of three things:

1) When deciding whether to increment "passes", both variance values have
an arbitrary value of 4 added to them. There's a sentence about this in
the earlier (big) comment, but it lacks any justification as to the chosen
value. What's worse, variance is not a plain number, but a quantity in the
same units as the base values. Since typically both clocks will run at
very difference frequencies, using the same (constant) value here has much
more of an effect on the lower frequency clock's value than on the higher
frequency one's.

2) The second of the "important formulas" is nothing I could recall or was
able to look up. All I could find are somewhat similar, but still
sufficiently different ones. Perhaps my "introductory statistics" have
meanwhile been too long ago ... (In this context I'd like to also mention
that it took me quite a while to prove to myself that the degenerate case
of, in particular, the first iteration wouldn't lead to an early exit
from the function.)

3) At the bottom of the loop there is some delaying logic, leading to
later data points coming in closer succession than earlier ones. I'm
afraid I don't understand the "theoretical risk of aliasing", and hence
I'm seeing more risks than benefits from this construct.

Beyond that there are implementation aspects that I'm not happy with,
like aforementioned delay loop not dealing with a TSC which did start
from a large "negative" value, and which hence would eventually wrap. Nor
is the SMI (or other long latency events) aspect being taken care of. But
any such concern could of course be dealt with as we port over this
logic, if we decided we want to go that route.

My main concern is with the goal of reaching accuracy of 1PPM, and the
loop ending only after a full second (if I got that right) if that
accuracy cannot be reached. Afaict there's no guarantee that 1PPM is
reachable. My recent observations suggest that with HPET that's
feasible (but only barely), but with PMTMR it might be more like 3 or
more.

The other slight concern I have, as previously voiced on IRC, is the use
of floating point here.

Jan

[1] 
https://cgit.freebsd.org/src/commit/?id=c2705ceaeb09d8579661097fd358ffb5defb5624




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.