On 2014-12-06, Charles Swiger <cswi...@mac.com> wrote:
>
>> On Dec 5, 2014, at 8:39 PM, William Unruh <un...@invalid.ca> wrote:
>>
>>>>> This is obviously false. What do you think /etc/ntp.drift is?
>>>>
>>>> It is the offset from the standard rate of the clock. That memory is
>>>> never used except on bootup. ntpd has to know how much to alter the
>>>> drift.
>>>
>>> Ah, so you acknowledge that your original statement was wrong.
>>
>
> That wasn't intended to be a trick question.
>
> Hmm. Unless one considers intellectual honesty to be tricky, perhaps....
>
>
>>> Just like your claim whether the chrony docs recommend using maxpoll=4
>>> across the network to a LAN timesource or not was wrong?
>>
>> I have given you the quotes from the chrony docs. Where do you get your
>> statement from?
>
> The chrony docs, section 5.3.4:
>
> http://chrony.tuxfamily.org/manual.html#How-can-I-improve-the-accuracy-of-the-system-clock-with-NTP-sources_003f
OK, lets quote the whole section
"The optimal polling interval depends on many factors, this includes the
ratio between the wander of the clock and the network jitter (sometimes
expressed in NTP documents as the Allan intercept), the temperature
sensitivity of the crystal oscillator and the maximum rate of change of
the temperature. An example of the directive for a server located in the
same LAN could be
server ntp.local minpoll 2 maxpoll 4 polltarget 30
"
Note the caveates : server located on the same lan. In fact more
frequent polling IS better especially when one uses the a system with
memory-- ie where the system uses the offsets measured for the last 64
times to figure out what the best time now is.
But, compare this with the actual documentation for chrony, not this
faq which I quoted, and you erased. (Minpoll 5 maxpoll 10)
>
>>> Just like your claim about whether ntpd cares about figuring out the local
>>> clock frequency or whether it only chases the offset was wrong?
>>
>> ntpd does not care about figuring out the local clock frequency.
>
> You keep repeating this assertion when it is quite obviously wrong.
>
> Above, you've acknowledged that ntp.drift contains the (frequency) offset
> for the clock. That's the single most important piece of data to have
> around even if the machine loses network connectivity with other timeservers,
> or ntpd is restarted, or the machine itself is rebooted.
It is ONLY used when the ntpd is started/restarted.
If it makes you feel happy, yes ntpd does know about the current drift
rate. It knows nothing about the past drift rate. That is what I call
memory. And in normal operation, it does not even know about the current
drift rate-- it is the operating system that does that. All ntpd does is
to change the current drift rate to try to minimize the offset.
IF the operating system is incapable of changing the clock rate, ntpd
tries to do it for the operating system. Every second it resets the
clock to take into account the error in the rate of the clock. In this
case, ntpd remembers the current drift rate. But only the current drift
rate. Again, it has no memory of the past.
Since you keep wanting to say I am wrong, why do you not tell us how
ntpd works in your understanding?
>
> Figuring out the local clock frequency is the most important thing
> ntpd does. Getting that right means that the local clock can be trusted
> to provide reasonably accurate time for a decent while even if freewheeling.
But it does not "figure out the clock frequency". It just changes the
clock frequency to try to eliminate the offset just measured.
Note that before it actually runs, it does remember the past 8 offsets
AND delays, These are not used in the ntp clock control algorithm. These
are used to select the one with the lowest delay, to feed to the
algorithm as the "current" offset, to use in changing the frequency,
and the rest are unused.
Note that ntpd also keeps itself in memory, so it remembers its own
code as well.
So to be perfectly clear, ntp does not remember past events to use, in
addition to the current event, in adjusting the rate of the clock.
That is what I call memory. That is what I call a non-Markovian process.
>
> (Or for the folks who don't care whether their noon is a minute off from
> real time, just so long as everything on the LAN in their isolated island
> is mutually synced and that there are 3600 computer seconds per hour of
> wall clock time.)
Which chrony and ntpd do well.
>
> Regards,
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
