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: <1243902599.11263.52.camel@jstultz-laptop>
Date:	Mon, 01 Jun 2009 17:29:59 -0700
From:	John Stultz <johnstul@...ibm.com>
To:	Rik van Riel <riel@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>, mingo@...hat.com, hpa@...or.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, 2009-06-01 at 20:06 -0400, Rik van Riel wrote:
> John Stultz wrote:
> > On Tue, 2009-06-02 at 01:22 +0200, Ingo Molnar wrote:
> 
> >> 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. 
> 
> Would this not be true already, because the convergence
> of Linux system suddenly became a lot slower in 2.6.19?

Yes, this is true. But some folks have considered Linux to have had a
faulty NTP implementation up until 2.6.19.

> Damned if we do, damned if we don't - except the new
> behaviour introduced by your patches is nicer.

It would seem this way, so I'm not throwing the patch out yet. I'm just
suggesting we hold off including it until we've tried attacking the
issue from a few other angles. Miroslav understands the details behind
the NTP protocol much better then I, so I'd like to try to address them
before going out on our own.

I just want to avoid the kernel from oscillating between fast(and maybe
incorrect)convergence and ntp-spec-compliance.

thanks
-john


--
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/