linux-kernel - Re: 2.6.19 -mm merge plans (NTP changes)

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: <Pine.LNX.4.64.0609251929030.6761@scrub.home>
Date:	Mon, 25 Sep 2006 19:38:36 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	ray-gmail@...rabbit.org
cc:	john stultz <johnstul@...ibm.com>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.19 -mm merge plans (NTP changes)

Hi,

On Mon, 25 Sep 2006, Ray Lee wrote:

> On 9/25/06, john stultz <johnstul@...ibm.com> wrote:
> > I was able to run tests for two days each w/ and w/o the patch I had
> > concerns about. And indeed, it seems if the drift file is reset, the
> > initial convergence is much slower (and this is really what worried me).
> > However once it converges it seems to keep sync as well as the current
> > code.
> 
> So slower convergence isn't a regression?

Not really, it makes the clock more stable and less suspectible to 
network delays.
I think a big part of the problem is that our calibration code could use 
some improvements, I've seen some widely different initial drift values 
from one reboot to the next, which is the main reason ntp has to do that 
much initial work in the first place.

bye, Roman
-
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/