William Unruh wrote:
On 2015-02-10, Jochen Bern <jochen.b...@linworks.de> wrote:
On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:
However, when I wait for several minutes, the time can be adjusted to
the right time. I couldn't see the gradual changes of offset. Is that
normal?
Assuming that you're using a minimalistic configuration: Yes.
ntpd would take almost three months to *gradually* eliminate (slew) one
hour of offset, so as soon as the
offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it
gave up all hope for the universe and "just set the clock" hard (step).
No. It only does that for "offsets from Hades". The Ones from Hell, ntpd
abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is
>1000 sec)
Ie, for <128ms, ntp will try to slew the clock ( at a max of 500PPM- as
far as I can see a completely arbitrary limit Mills decided on decades
The 500 ppm limit is not at all arbitrary!
In fact, it was originally just 100 ppm, but when too many systems
turned up with a system clock which was a bit too far out, Prof Mills
redid the control loop to allow a 500 ppm range.
It could have been a lot more, but the ultimate stability of the control
loop is supposed to be better this way.
My own control theory math was back around 1980, so I have forgotten
most of it. :-(
Terje
ago). If >128ms but <1000s it will, after being sure that that is not
just some measurement error, jump the time (ie infinite PPM) If >1000 it
assumes something is very very very badly wrong, and aborts.
However if this is the first time this running of ntpd has encountered
this, eg at startup, if you use -x option it will jump the time even if the
offset is >1000 sec.
Regards,
J. Bern
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
