[ntp:questions] FLL instability

unruh unruh at invalid.ca
Mon Jan 7 06:48:08 UTC 2013

On 2013-01-07, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> On 1/6/2013 3:45 AM, Mischanko, Edward T wrote:
>>> -----Original Message-----
>>> From: questions-
>>> bounces+edward.mischanko=arcelormittal.com at lists.ntp.org
>>> [mailto:questions-
>>> bounces+edward.mischanko=arcelormittal.com at lists.ntp.org] On
>>> Behalf Of David Taylor
>>> Sent: Sunday, January 06, 2013 2:18 AM
>>> To: questions at lists.ntp.org
>>> Subject: Re: [ntp:questions] FLL instability
>>> On 06/01/2013 06:29, Mischanko, Edward T wrote:
>>>> I have "tinker allan 7" in my ntp.conf, as recommended, but I
>>> notice that the frequency is adjusting wildly starting with
>>> polling at 128 seconds.  Is something wrong with the way FLL is
>>> implemented?
>>> []
>>> Where is this recommended?  URL, please.  I've never had the
>>> need to use
>>> this tinker myself, so I wonder whether it's some situation
>>> which
>>> doesn't apply to me.

>> This was recommended to me on this list several months ago.  I am running my windows client on a corporate LAN and it was suggested that the PLL would not correct fast enough at polling intervals over 128 seconds.  The problem I am seeing is that when FLL is implemented the frequency swings excessively and the offset does not train toward zero.  This would not be needed for setups using GPS/PPS reference clocks.

??? So do not have your system poll with intervals longer than 128 sec (
maxpoll 7) 
The tinkering with fll should only be done after a careful analysis of
the Allan variance of the clock and finding the minimum where frequency
drifts take over from clock jitter. 

"Doctor, when I keep hitting my head against the wall, it hurts". 

> Please use your "Return" or "Enter" key.  MicroSoft will let you write 
> lines in excess of 500 characters.  It's rather tough for many of us to 
> read it.
> You may have other problems but you should expect NTPD to need as long 
> as ten hours to settle.  If you are trying to run "9 AM to 5 PM you have 

That is to get to microsecond precision. For millisecond the time is
more like an hour or so. 

However it certainly is best not to bring down and restart ntpd every

> made some poor choices.  NTPD can take up to TEN HOURS to get the best 
> time you can get.  Once it's settled, it should not have any problem 
> maintaining synchronization.

More information about the questions mailing list