[ntp:questions] oscillations in ntp clock synchronization

David L. Mills mills at udel.edu
Tue Jan 15 15:32:52 UTC 2008


Unruh,

Assuming the residuals are in the low microseconds and the variation 
period is much longer than the time constant and the same in both NTP 
and chrony, it would seem very likely that what you see is due to small 
temperature changes. This is the same thing seen in our primary servers 
synchronized by GPS and PPS. They hold typically within a few 
microseconds but occasionally budge twice that. I have traced this to 
small variations in machine room temperature as the air conditioning 
system cycles.

Dave

Unruh wrote:

> a) NTP shows sign of the same instability. If you look at the bottom graph
> on www.theory.physics.ubc.ca/chrony/chrony.html at the black graph, it is
> ntp running off a GPS PPS. It also shows an oscillation of about 1.5hr. The
> amplitude is small (about 2-3 usec) but doing a fourier transform there is
> a strong peak. This is the same time frame as the oscillation in chrony,
> but much smaller amplitude of course.  Ie, it looks like both chrony and
> ntp have similar behaviour.
>  
> 
> b) Isn't this instability is too long a time frame for the PPL?
>  The rate of clock queries in chrony has a max of 7
> (2^7 sec) and a min of 2^4. Again, this is much shorter than the
> oscillation scale.  
> For ntp, the query using the shm ref clock driver, together with a gps
> interrupt routine running off the parallel port, the shm query time is 16
> sec, and ntp has minpoll 4
> 
> 
> 
> "David L. Mills" <mills at udel.edu> writes:
> 
> 
>>Bill,
> 
> 
>>If chrony does discipline the clock frequency, it would use some kind of 
>> phase-lock feedback loop (PLL). PLLs can show instability as you 
>>describe due to excessive loop gain. It gets pretty technical and a nerd 
>>treatment is in das Buch; however, the chrony designers should know 
>>about this and be able to correct it. The ntpd feedback loop stands on 
>>its head to avoid this problem, espcially as a scondary server with 
>>dependent clients; as this can be amplified and cause a whip effect.
> 
> 
>>Dave
> 
> 
>>Bill Unruh wrote:
>>
>>>I have been keeping track of the clocks on my various systems. One is
>>>synced using ntp from a GPS 18LVM pps source. The others are synced from
>>>that machine using chrony. Almost all of the systems have a very strange
>>>oscillation in them, with a time scale of about 1.5 hours. On the ntp
>>>system, this oscillation in the offset has an amplitude of about 2-3 usec.,
>>>while on the others, which use chrony, the oscillation is about 20 usec. 
>>>The periods are roughly the same ( within about 10%) on all the systems.
>>>These are especially obvious in the clock rates which are set by chrony,
>>>such that the rates have oscillation of about .5 PPM . 
>>>
>>>To add to the bizareness, the real time clocks, which chrony also monitors,
>>>also has oscillations in the rate chrony derives for the rtc. On some of
>>>the machines the rtc oscillations are in phase with the rate oscillations
>>>of the system, and on some they are out of phase. Now, if the rtc were
>>>itself a perfect clock, and if the rate oscillations in the system clock
>>>were due to some "instability" in the chrony or ntp algorithm, then you
>>>would expect to see the rtc oscillation be exactly the same size as the
>>>system oscillation, out of phase and the same amplitude. But most are in
>>>phase and all have amplitudes 2-10 times larger than the oscillation in the
>>>system. 
>>>
>>>(To see the data, see www.theory.physics.ubc.ca/chrony/chrony.html)
>>>Does anyone have the ghost of a clue as to what could be going on here?
>>>
>>>Note that exactly the same kind of oscillations can be seen in the ntp
>>>offset on the string computer, but with a period about 10-20% smaller than
>>>on the others, and an amplitude about 10 times smaller. 
>>>
>>>What it looks like is that both the chrony and the ntp algorithms are
>>>acting like amplifiers, with a huge peak  Q peak at around a frequency of 1.5hr.
>>>




More information about the questions mailing list