On 2014-12-05, David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 05/12/14 08:42, William Unruh wrote:
>
>> Nope. ntp changes the rate of the local clock to correct offsets. That
>> is all it does. It does not make the rate correct, and then the offset.
>
> Not true. It applies a correction for the offset, such that if that
> were the only error, it would be eliminated exponentially with a time
> constant that is related to the poll rate. I believe it expects to
> update this correction well before it is fully applied.
??? Not sure what you mean by "not true". ntpd corrects offsets by
changing the rate. ntp corrects rate changes by seeing the cumulative
offset changes and changes the rate to correct the offsets.
>
> At the same time, it applies a correction to the long term estimate of
> the frequency, with a much longer time constant.
>
>
>> much more quickly than ntpd does, for the same poll. Remember that ntpd
>> throws out 85% of the measurements it makes, in order to try (poorly) to
>
> If the round trip variability was sufficiently low that this pre-filter
> were not needed, any variations in the samples it is ignoring would be
> largely suppressed by the loop filters, which have time constants that
> are significantly longer than even eight times the poll interval. ntpd
> is heavily oversampling, which means that the min and maxpols quoted for
> chrony imply an even higher excess rate.
Those quotes were simply wrong.
to quote from the chrony docs
"3.4.2 Typical configuration files.
----------------------------------
To illustrate how a dial-up home computer might be configured, example
configuration files are shown in this section.
For the '/etc/chrony.conf' file, the following can be used as an
example.
server 0.pool.ntp.org minpoll 5 maxpoll 10 maxdelay 0.4 offline
server 1.pool.ntp.org minpoll 5 maxpoll 10 maxdelay 0.4 offline
server 2.pool.ntp.org minpoll 5 maxpoll 10 maxdelay 0.4 offline
...
"
Does that look any different from what ntpd recommends?
Also from the same document (chrony.txt in the docs that come with
chrony)
"'minpoll'
Although 'chronyd' will trim the rate at which it samples the
server during normal operation, the user may wish to constrain the
minimum polling interval. This is always defined as a power of 2,
so <tt/minpoll 5/ would mean that the polling interval cannot drop
below 32 seconds. The default is 6 (64 seconds).
'maxpoll'
In a similar way, the user may wish to constrain the maximum
polling interval. Again this is specified as a power of 2, so
<tt/maxpoll 9/ indicates that the polling interval must stay at or
below 512 seconds. The default is 10 (1024 seconds).
"
>
>
>>
>> Actually not true. How do you think the standards of the various
>> contries determine the accuracy of their clocks. They have no better
>> time standard to compare them with. And yet they confidently will quote
>> accuracy figures for their clocks. Study that.
>
> I presume that whatever time transfer mechanism they use has well
> characterised errors. NTP operates in an environment where the errors
> are not well characterised.
Not true. Remember that they are operating down at the sub nanosecond
level, and if you think transfer even across the room is well
characterized at that level,....
But anyway that comment of mine was not about transfer errors. It was a
reply tothe statement that the only way of characterizing the
uncertainty of clocks is to have one that keeps better time than the
clock one is looking at.
But to get back to the chrony vs ntpd:
chrony operates in an environment where the errors are not well
characterised as well. IF you are in an environment where there are
large (factors of 2) changes in the travel times in each direction, the
clock filter of ntpd might give better results. It is something that has
not AFAIK been tested. I am not sure what the answer would be.
HOwever, that is not true of most situations in which ntpd or chrony are
used. The dominant error is temperature fluctuations in which the clock
frequency wanders around. ntpd handles that badly. chrony handles it
better. So do you use a system which maybe protects you better in
unusual situations, or one wich handles the typical case better?
chrony could be altered to try to estimate whether or not one is in a
case where there are large fluctuations in the travel times giving
fluctuating assymetries in the travel time, and if so apply something
like the ntpd clock filter. But it would have to be pretty bad I think
before it became necessary.
It would be a good master's project for someone to do the comparison.
>
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
