linux-kernel - Re: [GIT pull] ntp updates for 2.6.31

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090623143323.GA13932@localhost>
Date:	Tue, 23 Jun 2009 16:33:23 +0200
From:	Miroslav Lichvar <mlichvar@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	John Stultz <johnstul@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT pull] ntp updates for 2.6.31

On Tue, Jun 23, 2009 at 03:36:25PM +0200, Ingo Molnar wrote:
> > I think John's tests were done on LAN and in an environment with 
> > sudden temperature changes. This is the case where frequency 
> > variations strongly dominate the noise and faster PLL performs 
> > better.
> 
> I'd also expect this to be quite similar to most everyday Linux 
> uses.

I'd say that most users keep the default distribution configs, i.e.
syncing over internet to servers from pool.ntp.org. The network jitter
is in hundreds of microseconds or even miliseconds and the temperature
changes are dominated by the noise.

> > Other NTP clients don't have to use the PLL interface. For 
> > example, chrony uses only the SINGLESHOT mode and sets the 
> > frequency directly. It has an adaptive model using linear 
> > regression, it converges really fast and in my tests performs 
> > better than NTP.
> 
> That's good. Could this be integrated into the kernel, for even 
> better results?

The code is quite complex with possibly lot of room for improvement.
I think it's better to keep it in userspace. There are two things that
would help chrony on kernel side though. Supporting nanosecond offset
in the SINGLESHOT mode and updating the reported offset with every
adjtimex call, not only once per second, so chrony would know exactly
how much of the offset was already applied.

> > I'm not very familiar with the PPS API, is there something wrong 
> > with it?
> 
> The PPS patches i've seen just export IRQ timestamps to user-space.
> 
> That is not very robust in my opinion when it comes to do time 
> approximations - to get quick, low-latency action and precise 
> measurements it's best to keep the critical path as short as 
> possible, and within a single source code repository: i.e. within 
> the kernel.

That's what kernel PPS discipline does, it will be probably included
later. Its performance is an order or two better than the PLL/FLL
discipline.

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