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: <20090602162208.GA15696@localhost>
Date:	Tue, 2 Jun 2009 18:22:08 +0200
From:	Miroslav Lichvar <mlichvar@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Rik van Riel <riel@...hat.com>, John Stultz <johnstul@...ibm.com>,
	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:timers/ntp] ntp: adjust SHIFT_PLL to improve NTP
	convergence

On Tue, Jun 02, 2009 at 02:20:39AM +0200, Ingo Molnar wrote:
> > Would this not be true already, because the convergence of Linux 
> > system suddenly became a lot slower in 2.6.19?
> >
> > Damned if we do, damned if we don't - except the new behaviour 
> > introduced by your patches is nicer.
> 
> Not just that - but there's calibration noise during bootup that can 
> cause randomly distributed recalibrations as well. So other hosts in 
> a mixed environment will see inconsistencies anyway, after every 
> bootup.
> 
> NTP is all about being able to be resilient against time noise and 
> being able to sync up to a common time base ASAP.

There has to be a compromise between frequency and offset noise. When
SHIFT_PLL is set to 2 the frequency noise will be higher and that will
have a negative impact on the long-term ability to keep the clock
accurate. The error will grow faster when network connection is
suspended.

The PLL response can be configured to be the same as the proposed
SHIFT_PLL 2 by decreasing the time constant value in adjtimex
structure, so I'd rather keep following the NTP specification and
control it from userspace if necessary.

As for the calibration issue, would it be possible to export the
information that an instable clocksource is used and when was the last
time it was calibrated? Then we'd know when the drift file should not
be trusted and let NTP calculate the frequency directly (it takes
about 15 minutes).

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