[chrony-users] Re: Why doesn't chrony provide a "maximum error" like ntpd does?

[Abis BIso]

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.

[Bill Unruh]

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: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
UBC, Vancouver,BC _|_ Program in Cosmology |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Abis BIso

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.
--
"unsubscribe" in the subject.
subject.

[Abis BIso]

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.

Are the above steps to right direction?

Thank you for your time. :)

Post by Bill Unruh
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: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
Canada V6T 1Z1 ____|____ and Gravity ______|_
www.theory.physics.ubc.ca/

Post by Abis BIso

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.
with "unsubscribe" in the subject.
in the subject.

--
"unsubscribe" in the subject.
in the subject.

[Bill Unruh]

William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
UBC, Vancouver,BC _|_ Program in Cosmology |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Abis BIso
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.

Post by Abis BIso
Are the above steps to right direction?
Thank you for your time. :)

Post by Bill Unruh
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: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Abis BIso

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.
"unsubscribe" in the subject.
the subject.

--
"unsubscribe" in the subject.
subject.

--
"unsubscribe" in the subject.
subject.

[Abis Biso]

I see.
If it is a local network then I guess it does not matter if I poll my time server every couple of seconds, does it?

Sent from my iPhone

Received: from mx1.tuxfamily.net ([212.85.158.8]) by mx-ha.gmx.net (mxgmx112
[212.227.17.4]) with ESMTPS (Nemesis) id 0Lqliw-1fF2bo2oWQ-00eOtX for
Received: from listengine (helo=tuxfamily.org)
by mx1.tuxfamily.net with local-bsmtp (Exim 4.84_2)
id 1ejqWo-00021Z-4T
Received: from info.physics.ubc.ca ([142.103.234.23]) by mx1.tuxfamily.net
08 Feb 2018 19:02:25 +0100
Received: by info.physics.ubc.ca (Postfix, from userid 1000) id A61CDA25A4;
Thu, 8 Feb 2018 10:02:23 -0800 (PST)
Date: Thu, 8 Feb 2018 10:02:23 -0800 (PST)
Subject: Re: [chrony-users] Re: Why doesn't chrony provide a "maximum
error" like ntpd does?
User-Agent: Alpine 2.03 (LMD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
List-Software: Listengine, VHFFS 4.7-dev-2b25a01d00
List-ID: <chrony-users.chrony.tuxfamily.org>
List-Archive: <http://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-users>
Precedence: list
X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3;
X-UI-Filterresults: notjunk:1;V01:K0:dzpxWsUYDsk=:o1T8OAyO5mGh0TWwuLCwIMtpT/
9iYJCTm08UWiKF9K0xDpn5Gc6/yuHzzcJ0BFsiqR1g5Be3eRJuecTHYTMq/vpFfMJ4rbKy44f
a/85jIXfM2hUC3baftDEKXts2AqbQ7XtHAtAgUyWDv3i27yUQAuhu1KMBp4keWzuBfBUpBFE7
PNHo5QzwYWbFbuVch2Of5sbM4aQC1Bx9/m2bl3OdXlBenGkLWq3aPbGVoX5siYl5+OhgZH3ss
jlRB5rumspY9r2c3IiOUEWd2AIqGuoL+9pLwSGEqVA5EwL/6jQQ6zj8P/nTkrZhM/cRnhfO+L
jiL+tEnacNwbDB5CQxF8IK5HLk9/VbZrkiAgYKfVGRw796hIRbQ1A9zdMzz6pBG4vdiszVI29
vTpNp723LWczjrOfqQBBxmD2b6D6oWKYY+43ircAg0/R5GhQ8tdBFypv92MSUeZDXy38yw83E
hcJHE+m7XrVQip2kO7ioYPrKoklVwXEVZu4DffQ82qd2uUiwg/q+ahDHiI46A3nfWBj2Du71F
dwXhOj5g/E64IF94jY5fJyKIVzk+2PjzszkIkywCHVHqyYTc0OCLGlETai+EV/eT4/6A+08cQ
5c8lZ8uCITAmenEcztJuMzE9uEpa5lP1fTKbrC5DAn4Qa2252I0DKZ4Klmq9iYvcevpMcX6I6
WcR3TOqfk4jUyGVwXlLYD9hxscCw/N5DCIbfgDU0ZL5aij1blIGtxZof+zc6ZtqdSjqdxTN0C
VmEcJlHC3RUfrbO2Uke7kQ/NAVB1+8SDcJMhuY0CcbIaIf2Qq3J7QR5zgq9CpHVjJC73EUdoE
oJu9ce80aLcwSXQJg9sQeFohaA7tGQzN4wLnXH4vFVsJdEIyfSsjctKE3tdpUPT1rvfHBWJAP
qyIeyhRR5ojoMqiUR9WsibtOVGSWfWvUvmP/fDGBf9sSC980z0qysj3VW/C1r90gn7SWLcjzQ
q1uNjt8oSZswOB2xDM3QGjezfXD0SkiV5jircko91DuuVEOp4IdhseIhOYGFUF1Mf3YgjOz62
RZiftL3glnUW5VpwsQwzypHHZBD0yW/7GBi4heX4lFYiT0Z0MQ6JippE8ZXKDHPteQoDpa1Fm
SWshXAKtkygiJF2dhvWBY1NA8d5nzU99YDnDOVT5GT2utmE+OQBuF93sP1VhA/DkiQng2akzF
pjvcetOE910faYs4kgtgnoTbnVFMs+vqMxjXFwXethYeAr2aiVdAIatITwYWRaWZY+uesX07y
K1Y5LS3vjoXYWNG5BPY68ONp5ZN5AqM5StWWQ5zgdlqgfDVKp5jycvfzxqblc4Eb6RfiYJwIB
WdvVodIxzMCe92kGGySisZeb3uNdUpFglfy9SInuJzwoSklMh5DM6BT6yvI/VOXMgW3ZSMMdo
H5WiC1Ms6p4xLjBeC+5nwMIZ6gghSZ9lF8VwK4ymjVlvZk1AvdFxT7DV0P5PUbPEqqQlqGhv+
puskCBa5YrMpPULBHjcvlJyP56Ifz9vo42FwYrtz4SGN6/MCde52lFJArPEpH8WE2/K/lb+Iq
+bWsBugEqUCcCmZds3WNNymtGt38cZy50HkFmVtD/rCmulEPLT8oEZAiSRfbT8QykXopGRmLs
FnHBrgI63UXVHg6cQy7uobs8GrBxQkznEmZsBLLUKi+GlofmqovR6lN6YFDTLjr63vGNK2CR2
oI=
William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Abis BIso
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.

Post by Abis BIso
Are the above steps to right direction?
Thank you for your time. :)

Post by Bill Unruh
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: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Abis BIso

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.

--

--

--
William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Abis BIso
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.

Post by Abis BIso
Are the above steps to right direction?
Thank you for your time. :)

Post by Bill Unruh
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: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Abis BIso

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.

--

--

--