Edward,
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.
Dave,
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....@lists.ntp.org
[mailto:questions-bounces+edward.mischanko=arcelormittal....@lists.ntp.o
rg] On Behalf Of unruh
Sent: Saturday, April 23, 2011 1:20 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Bug 1700 - Clock drifts excessively at
pollinglevels above 256.
On 2011-04-22, Mischanko, Edward T <edward.mischa...@arcelormittal.com>
wrote:
256.
My system clock drifts excessively when polling above 256 in a Windows
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 have
made
are global in nature and really only need changes in the Windows port.
I would welcome a patch to the Windows port to accomplish these
changes
or any other changes that accomplish the 1 ms stability I have now
achieved. I hope Dr. Mills will have constructive comments on this
problem and proposed solutions.
Does your system cpu use powersaving cpu frequency changes? Is it a
virtual Windows machine?
*/
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
