| Re: [chrony-users] Re: Why doesn't chrony provide a "maximum error" like ntpd does? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
On Thu, 8 Feb 2018, Abis BIso wrote:
Ok, makes sense.
So the important bit here is to keep these two values as small as possible
and more importantly as "stable" as possible, yes?
This way, "jitter", be it network or dispersion, will be low, giving a change
to the daemon to keep the offset close to upstream.
And a good way to achieve this is to poll the server as much as you can
afford, plus keep the link as uncongested as possible.
No, that is not necessarily the best way. There is a tradeoff between offset
and rate. If you poll frequently, then the time between measurements is small
and the uncert in the measurement makes the rate very uncertain. The clocks
rate is not only variable, but it is also fluctuating a lot. This also tends
to bring down chrony's "goodness of linear fit" estimate, and means it also
tends to use fewer events to fit the measurements to a straight line. While
the clock may be kept tighter to the remote clock (that remote clock may get
very annoyed with you for using so much of their resources by your incessant
polling as well) but the rate of your own clocks is worse. Thus, if for any
reason polling stops for a while(your internet goes down for example, or your
source goes offline for a while )your clock will drift much more than it
should because the rate uncertainty is so large. Ie, to keep a tight control
of the rate, you need to measure less often.
Are the above steps to right direction?
Thank you for your time. :)
On Thu, 8 Feb, 2018 at 5:26 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
No, it is as said, the maximum uncertainty possible. It is certainly not
usual
that one leg of the transmission takes all the time, and other leg no time
at
all. It is certainly not true that the server's clock is off by its own
maximum amount. Thus it is not a good metric of uncertainty.
One can use the fluctuations in the time, but there may be biases in that.
Ie,
a good metric of the true uncertainty is hard.
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
On Thu, 8 Feb 2018, Abis BIso wrote:
Sounds like it basically the roundtrip-time/2 +max uncert in the server
time. Not that that is a terribly useful number.
Why do you think this is not a useful number?
Isn't this the way to calculate the error of the spot, or RMS, offset you
get with chronyc tracking?
As a matter of fact, should this number be used as a metric of uncertainty
and not, then what should be used?
Thanks.
-- To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with
"unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "help" in
the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with
"unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "help" in the
subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with
"unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "help" in the
subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.