[ntp:questions] Bug 1700 - Clock drifts excessively at polling levels above 256.

Mischanko, Edward T Edward.Mischanko at arcelormittal.com
Sun Apr 24 13:06:19 UTC 2011



Dr. Mills,


Happy Easter.  Thank you for your constructive comments.  I am unable to
run your suggested test because I currently don't have the knowledge and
means to introduce that small of an error.  Through expimentation, I
have found that adjusting the CLOCK_PLL to 1.8 and CLOCK_FLL to .001 has
given great stability to the system clock at polling levels above
8(256).  Changes to CLOCK_LIMIT and CLOCK_PGATE were made to allow for
quicker polling adjustments if they are still needed.  I am incouraging
more testing of the Windows port to verify both my complaint and
possible solution.  The changes I made to ntp_loopfilter.c are global,
but what I am advocating is a change to the Windows port only, because I
have not seen the problem on my FreeBSD stratum 1 server.




#define CLOCK_MAX       .128                    /* default step
threshold (s) */

#define CLOCK_MINSTEP   300.                    /* default stepout
threshold (s) */

#define CLOCK_PANIC     1000.                   /* default panic
threshold (s) */

#define CLOCK_PHI       15e-6                   /* max frequency error
(s/s) */

#define CLOCK_PLL       1.8                     /* PLL loop gain (log2)

#define CLOCK_AVG       8.                      /* parameter averaging
constant */

#define CLOCK_FLL       .001                    /* FLL loop gain */

#define CLOCK_LIMIT     15                      /* poll-adjust threshold

#define CLOCK_PGATE     2.                      /* poll-adjust gate */








From: David L. Mills [mailto:mills at udel.edu] 
Sent: Sunday, April 24, 2011 2:48 AM
To: Mischanko, Edward T
Cc: unruh; questions at lists.ntp.org
Subject: Re: [ntp:questions] Bug 1700 - Clock drifts excessively at
pollinglevels above 256.



I don't know enough about the mechanism Windows uses to adjust the
system clock. If some variant of the Unix adjtime(), the solution may be
straightforward. The phase-lock loop parameters determine the risetime
and overshoot of the discipline loop, in particular the loop gain and
corer frequency. The Unix discipline loop is carefully designed for
minimum risetime consistent with controlled overshoot of about six
percent  The loop is designed to preserve this characteristic over a
wide time constant an poll interval range from 8 s to 36 hr, but with
the FLL in use at the longer time constants. The most critical parameter
is the loop gain, which depends primarily on the timer frequency. In
most Unix systems this is 100 Hz, but in some systems it can be as high
as 1000 Hz with a change in parameters. It would not be feasible here to
summarize in detail how to establish these parameters; however, Chapter
4 of both the first and second edition of the boot "Network Time
Synchronization: the NTP Protocol on Earth and in Space," CRC Press,,
has the mathematical basis.

Here is a quick litmus test. With the client in normal operation with
the pool interval at 6 (64 s) and the time and frequency settled down,
introduce a 100-ms step in time. The discipline loop should converge to
zero in about 3000 s and overshoot about six percent. If the response is
far different than that, major surgery is required.


Mischanko, Edward T wrote: 

Your question is a very good one that I don't know the answer to.  I
have observed this behavoir while actually watching NTP Time Server
Monitor by Meinberg, live.  I didn't anticipate any power saving
features as being active.  I have seen a correction in the behavior by
changing the PLL and FLL gains, as noted.  I haven't specifially looked
for this problem in other ports, only Windows and only on systems
without a referrence clock.
-----Original Message-----
From: questions-bounces+edward.mischanko=arcelormittal.com at lists.ntp.org
[mailto:questions-bounces+edward.mischanko=arcelormittal.com at lists.ntp.o
rg] On Behalf Of unruh
Sent: Saturday, April 23, 2011 1:20 PM
To: questions at lists.ntp.org
Subject: Re: [ntp:questions] Bug 1700 - Clock drifts excessively at
pollinglevels above 256.
On 2011-04-22, Mischanko, Edward T <Edward.Mischanko at arcelormittal.com>
<mailto:Edward.Mischanko at arcelormittal.com> 

	My system clock drifts excessively when polling above 256 in a
	environment, as much as 5 ms or more.  I have made changes to
	.../ntpd/ntp_loopfilter.c CLOCK_PLL, CLOCK_FLL, CLOCK_LIMIT, and
	CLOCK_PGATE to address this problem.  I realize the changes I


	are global in nature and really only need changes in the Windows
	I would welcome a patch to the Windows port to accomplish these


	or any other changes that accomplish the 1 ms stability I have
	achieved.  I hope Dr. Mills will have constructive comments on
	problem and proposed solutions.

Does your system cpu use powersaving cpu frequency changes? Is it a
virtual Windows machine?


questions mailing list
questions at lists.ntp.org
questions mailing list
questions at lists.ntp.org


More information about the questions mailing list