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] [day] [month] [year] [list]
Message-ID: <20170109103143.1262fd1a@xeon-e3>
Date:   Mon, 9 Jan 2017 10:31:43 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     "Alex Ng \(LIS\)" <alexng@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        John Stultz <john.stultz@...aro.org>,
        "devel\@linuxdriverproject.org" <devel@...uxdriverproject.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 3/4] hv_util: use do_adjtimex() to update system time

On Mon, 09 Jan 2017 19:14:30 +0100
Vitaly Kuznetsov <vkuznets@...hat.com> wrote:

> Stephen Hemminger <stephen@...workplumber.org> writes:
> 
> > On Mon, 09 Jan 2017 18:40:15 +0100
> > Vitaly Kuznetsov <vkuznets@...hat.com> wrote:
> >  
> >> Stephen Hemminger <stephen@...workplumber.org> writes:
> >>   
> >> > An alternative would be for hyper-v util to provide a clocksource device and
> >> > let NTP manage the adjustment. The advantage of this would be HV util not fighting
> >> > with NTP, and using standard API's. The downside would be the complexity of configuring
> >> > NTP, and difficulty of writing a clock source pseudo device.    
> >> 
> >> Yes, I see this option. But as I wrote to John I'm afraid we'll have to
> >> come up with a custom interface from hv_util to userspace which no NTP
> >> server will want to support (because, first of all, it's not about
> >> 'network time' any more). We can write our own daemon which will read
> >> from this interface and do adjtimex but in this case I don't see much
> >> value in this data traveling from kernel to userspace and back...
> >>   
> >
> > Master NTP servers are connected to authoritative clock sources. I have no idea how
> > that is configured, but it should be possible.  
> 
> As far as I understand these servers are connected to GPS receivers or
> something like that and we can probably pretend being one but I'm not
> sure that the TimeSync v4 protocol fits there, we'll probably lose the
> precision - currently we calculate the delta in a small kernel function
> with interrupts disabled, in my tests I see it floating around several
> hundred - few thousand nanoseconds from host's time.

My understanding is that NTP doesn't work very well at small time intervals.
Probably the ideal solution is something where kernel corrects time but
there is also way to communicate to NTP server that the kernel time is being maintained by
other entitity.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ