lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 23 Jan 2017 20:44:53 +0100
From:   Paolo Bonzini <>
To:     Richard Cochran <>,
        Marcelo Tosatti <>
        Radim Krcmar <>,
        Miroslav Lichvar <>
Subject: Re: [patch 4/5] PTP: add PTP_SYS_OFFSET emulation via cross
 timestamps infrastructure

On 23/01/2017 19:44, Richard Cochran wrote:
>> device clock	   |sample1P,deviceclock|       |sample2P,deviceclock|
>> -------------------------------------------------------------
>> realtime clock  |sample1P,realtimeclock|     |sample2P,realtimeclock|
> Are |sample1P,deviceclock| and |sample1P,realtimeclock| taken at the
> same instant in time?
> If not, then calling that PTP_SYS_OFFSET_PRECISE is misleading.

Yes, of course.  This was added for the e1000e drivers first, but chrony
isn't using it yet.  In the case of KVM, the same host TSC value is used
to produce the host clock and (converted to guest TSC) the guest clock.

If you just implement getclock64 the PTP_SYS_OFFSET output:

device clock	|	|sample2|	|sample4|	|sample6| ...
realtime clock  |sample1|       |sample3|	|sample5|

has a very large distance between samples on the same line (about 1 us),
and I think it is too noisy for userspace to make sense of the output.

So, on one hand chrony only uses the mean of realtime clock samples, in
an attempt to produce precise cross timestamps.  On the other hand, even
though KVM could produce those natively, chrony does not support

Marcelo's patch then produces fake realtime clock samples that, however,
let chrony derive the cross timestamps that KVM produced in the first
place.  The outcome is really great accuracy compared to previous
versions of the patch, often just +/- 2 or 3 nanoseconds.


> Still don't get what you are doing here...

Powered by blists - more mailing lists