Re: [GIT pull] ntp updates for 2.6.31

[Ingo Molnar <mingo@elte.hu>]

* Miroslav Lichvar <mlichvar@redhat.com> wrote:

> On Tue, Jun 23, 2009 at 11:57:45AM +0200, Ingo Molnar wrote:
> > > > Wouldnt the goal be to calibrate as fast as possible? (Without 
> > > > any bad oscillation)
> > > 
> > > Not really. It depends on how noisy is the input signal. On an 
> > > idle LAN the jitter is just few microseconds, but over internet it 
> > > easily reaches miliseconds. Over a certain point faster PLL will 
> > > just make things worse.
> > 
> > That is what i called 'bad oscillation' - a 'too fast' PLL that 
> > over-compensates and does not converge well enough.
> > 
> > Is there a claim that this change causes that? (John's testing 
> > suggested that there's no such effect)
> 
> 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.

> On the opposite side is an idle machine in a room with stable 
> temperature syncing over wireless or dial-up. I don't have access 
> to such machine, but in simulations (noise with exponential 
> distribution) I see that offset RMS doubles when the time constant 
> is decreased by 2.

The thing is, an idle machine in a room with stable temperature is 
in a good position anyway to have stable time, right? We should 
rather care about the common-case of temperature variations, 
reboots, etc.

That is where NTP _helps the most_ - as the physical environment is 
very entropy laden to begin with.

> Maybe for most of the users the change would be an improvement. I 
> don't have any statistics to back it up or claim otherwise. 
> However, if the constant needs to be adjusted, it's better to do 
> it in NTP.
>
> > > PLL is mainly about handling the signal noise, frequency adjusting 
> > > is secondary. When the noise is very low or the update interval is 
> > > long enough, the frequency variations caused by temperature 
> > > changes will dominate the signal noise and this is where FLL 
> > > should kick in.
> > > 
> > > The PLL/FLL switching is controlled by update interval. Ideally it 
> > > would be adaptive, but NTP is not that sophisticated. By default, 
> > > FLL is enabled when the interval is longer than 2048 seconds. This 
> > > is of course not the optimal value for all systems.
> > > 
> > > Unfortunately in kernel it can be configured only to 2048 or 256 
> > > and NTP never uses the shorter one. The NTP daemon has its own 
> > > loop which can be used instead and it allows to use arbitrary 
> > > values though.
> > 
> > How about going towards the ideal, adaptive design, to which ntpd 
> > passes in time samples and which observes noise and converges as 
> > quickly as possible (given the noise level) and stays stable once 
> > there? I guess we need extensions to the NTP syscall for that.
> 
> Not sure how hard that would be. The ntp-hackers list is a better 
> place to discuss such modifications.
> 
> 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 NTP code in kernel/time/ntp.c is now reasonably clean for 
> > efforts like that.
> > 
> > It would also pave the way to properly support PPS devices in 
> > the kernel. Would you be interested in things like this?
> 
> 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.

There's little policy really, other than setting some general 
parameters. NTPd can still provide the raw _network time_ 
timestamps, as that is probably best fetched by user-space and fed 
to the kernel.

	Ingo