lists.openwall.net   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  linux-cve-announce  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:   Wed, 18 Jan 2017 14:36:14 +0100
From:   Miroslav Lichvar <mlichvar@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Marcelo Tosatti <mtosatti@...hat.com>,
        Radim Krcmar <rkrcmar@...hat.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Richard Cochran <richardcochran@...il.com>
Subject: Re: [patch 3/3] PTP: add kvm PTP driver

On Wed, Jan 18, 2017 at 01:46:58PM +0100, Paolo Bonzini wrote:
> On 18/01/2017 13:24, Marcelo Tosatti wrote:
> >> Testcase: run a guest and a loop sending SIGUSR1 to vcpu0 (emulating
> >> intense interrupts). Follows results:

> >> Do you still want to drop it in favour of simplicity?

> It's just that it's not obvious why you get better results with biased
> host timestamps.  What makes the biased host timestamp more precise?
> 
> I'd rather use PTP_SYS_OFFSET_PRECISE instead, but unfortunately chrony
> does not support it---but I would still prefer you to support
> PTP_SYS_OFFSET_PRECISE as well.

Interesting. I wasn't aware that there is a new ioctl for measuring
the HW-sys offset. Adding support to chrony shouldn't be difficult.

If I understand it correctly, PTP_SYS_OFFSET can be emulated on top of
PTP_SYS_OFFSET_PRECISE simply by copying the sys_realtime and device
fields to corresponding ts slots. The apparent delay will be zero, but
that's ok if the conversion is really accurate.

I'm not sure if trying to do that in the opposite direction is a good
idea. An application using PTP_SYS_OFFSET_PRECISE may assume the
conversion is accurate and not include any delay/dispersion in an
estimate of the maximum error, which is needed in NTP for instance.

If we know the host timestamp ts[1] is not in the middle between the
guests timestamps ts[0] and ts[2], but rather closer to ts[2], why not
simply shift ts[1] by (ts[2]-ts[0])/2 ?

-- 
Miroslav Lichvar

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ