On Tue, 2025-02-11 at 08:58 +0100, Maciek Machnikowski wrote:

On 2/11/2025 1:46 AM, Jakub Kicinski wrote:

quoted

On Sun, 9 Feb 2025 12:33:24 +0000 Vadim Fedorenko wrote:

quoted

Yes, we have seen this patchset, and we were thinking of how to
generalize error_bound property, which was removed from the latest
version unfortunately. But it's a good point to look at it once
again in terms of our prototype, thanks!

I was wondering whether they have a user space "time extrapolation
component" which we should try to be compatible with. Perhaps they
just expect that the user will sync system time.

error_bound has a different purpose - it tries to get the "baseline"
clock accuracy from the HW. The number returned here is needed to
calculate the uncertainty, not to extrapolate.

And yes - AFIK AWS suggests system time sync for EC2 instances [1]

[1]
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configure-ec2-ntp.html

Right, error bound gives you a min/max for what the time can possibly
be, and that allows you to know whether certain transactions/timestamps
could *possibly* overlap, or if there is a known ordering between them.

There are libraries in userspace which handle this, to be used by
things like distributed databases. https://github.com/aws/clock-bound

The error bound is also exposed by the vmclock device which is now
supported in Linux (https://git.kernel.org/torvalds/c/205032724226) and
QEMU (https://gitlab.com/qemu-project/qemu/-/commit/3634039b93cc5),
although QEMU doesn't actually expose time through it yet, only the
fact that time has been *disrupted* e.g. through live migration).

(The PHC discussed here allows each guest on the system to do the same
work of carefully calibrating the *same* underlying hardware
oscillator; with vmclock the host does it once and then just tells the
guests the result through a shared memory structure. With the added
bonus of still being accurate immediately after live migration to a new
host.)