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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ