linux-kernel - Re: [tip:timers/ntp] ntp: adjust SHIFT

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]

Message-ID: <2c0942db0906012039ha1046abqe32951b57f40c0f4@mail.gmail.com>
Date:	Mon, 1 Jun 2009 20:39:18 -0700
From:	Ray Lee <madrabbit@...il.com>
To:	John Stultz <johnstul@...ibm.com>
Cc:	Ingo Molnar <mingo@...e.hu>, mingo@...hat.com, hpa@...or.com,
	riel@...hat.com, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org,
	Miroslav Lichvar <mlichvar@...hat.com>
Subject: Re: [tip:timers/ntp] ntp: adjust SHIFT_PLL to improve NTP convergence

On Mon, Jun 1, 2009 at 4:58 PM, John Stultz <johnstul@...ibm.com> wrote:
> On Tue, 2009-06-02 at 01:22 +0200, Ingo Molnar wrote:
>> * John Stultz <johnstul@...ibm.com> wrote:
>> > On Wed, 2009-05-06 at 09:46 +0000, tip-bot for john stultz wrote:
>> > > ntp: adjust SHIFT_PLL to improve NTP convergence
>> > >
>> > > The conversion to the ntpv4 reference model
>> > > f19923937321244e7dc334767eb4b67e0e3d5c74 ("ntp: convert to the NTP4
>> > > reference model") in 2.6.19 added nanosecond resolution the adjtimex
>> > > interface, but also changed the "stiffness" of the frequency adjustments,
>> > > causing NTP convergence time to greatly increase.
>> > >
>> > > SHIFT_PLL, which reduces the stiffness of the freq adjustments, was
>> > > designed to be inversely linked to HZ, and the reference value of 4 was
>> > > designed for Unix systems using HZ=100.  However Linux's clock steering
>> > > code mostly independent of HZ.
>> > >
>> > > So this patch reduces the SHIFT_PLL value from 4 to 2, which causes NTPd
>> > > behavior to match kernels prior to 2.6.19, greatly reducing convergence
>> > > times, and improving close synchronization through environmental thermal
>> > > changes.
>> > >
>> > >
>> > > [ Impact: tweak NTP algorithm for faster convergence ]
>> >
>> >     So I've been speaking with Miroslav (cc'ed) who maintains
>> > the RH ntpd packages, and he's concerned that this patch takes us
>> > out of NTP's expected behavior, which may cause problems when
>> > dealing with non-linux systems using NTP.
>>
>> I might be missing something here - but Linux converging faster
>> seems like a genuinely good thing. What non-Linux problem could
>> there be? Linux's convergence is really Linux's private issue.
>
> Yea. It does seem that way. Miroslav can likely expand on the issue to
> help clarify, but as I understand it, the example is if you have a
> number of systems that are peers in an NTP network. All of them are
> using the same userland NTP daemon. However, if the rate of change that
> corrections are applied is different in half of them, you will have
> problems getting all the systems to converge together.

Your point is clear, however -- reasonably speaking --  how many
instances will there be out there of networks of peers partially
upgraded versus lone systems slowly or never converging off of
masters?

By my naive understanding, the latter would strongly outnumber the former.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/