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

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 ]
To: chrony-users@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [chrony-users] Re: Why doesn't chrony provide a "maximum error" like ntpd does?
From: Abis Biso <abis.biso@xxxxxxx>
Date: Thu, 8 Feb 2018 19:02:18 +0000
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

> On 8 Feb 2018, at 18:02, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
> 
> Return-Path: <listmaster@xxxxxxxxxxxxx>
> 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
> <abis.biso@xxxxxxx>; Thu, 08 Feb 2018 19:02:34 +0100
> Received: from listengine (helo=tuxfamily.org)
>    by mx1.tuxfamily.net with local-bsmtp (Exim 4.84_2)
>    (envelope-from <listmaster@xxxxxxxxxxxxx>)
>    id 1ejqWo-00021Z-4T
>    for abis.biso@xxxxxxx; Thu, 08 Feb 2018 19:02:34 +0100
> Received: from info.physics.ubc.ca ([142.103.234.23])    by mx1.tuxfamily.net
> with smtp (Exim 4.84_2)    (envelope-from <unruh@xxxxxxxxxxxxxx>)    id
> 1ejqWe-00021I-V3    for chrony-users@xxxxxxxxxxxxxxxxxxxx; Thu,
> 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)
> From: Bill Unruh <unruh@xxxxxxxxxxxxxx>
> To: chrony-users@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [chrony-users] Re: Why doesn't chrony provide a "maximum
> error" like ntpd does?
> In-Reply-To: <1518111322.18780.1@xxxxxxxxxxxx>
> Message-ID: <alpine.LMD.2.03.1802080956320.8827@xxxxxxxxxxxxxx>
> References: <1518071952.3886.7@xxxxxxxxxxxx>
> <alpine.LMD.2.03.1802080921350.2937@xxxxxxxxxxxxxx>
> <1518111322.18780.1@xxxxxxxxxxxx>
> User-Agent: Alpine 2.03 (LMD 1266 2009-07-14)
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> List-Unsubscribe: <mailto:chrony-users-request@xxxxxxxxxxxxxxxxxxxx?subject=unsubscribe>
> List-Subscribe: <mailto:chrony-users-request@xxxxxxxxxxxxxxxxxxxx?subject=subscribe>
> List-Help: <mailto:chrony-users-request@xxxxxxxxxxxxxxxxxxxx?subject=help>
> List-Software: Listengine, VHFFS 4.7-dev-2b25a01d00
> List-ID: <chrony-users.chrony.tuxfamily.org>
> List-Post: <mailto:chrony-users@xxxxxxxxxxxxxxxxxxxx>
> List-Archive: <http://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-users>
> Precedence: list
> Reply-To: chrony-users@xxxxxxxxxxxxxxxxxxxx
> Envelope-To: <abis.biso@xxxxxxx>
> 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: +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.
> 
> 
> 
> 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.
> 


--
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.
References:
- [chrony-users] Re: Why doesn't chrony provide a "maximum error" like ntpd does?
  - From: Abis BIso
- Re: [chrony-users] Re: Why doesn't chrony provide a "maximum error" like ntpd does?
  - From: Bill Unruh
- Re: [chrony-users] Re: Why doesn't chrony provide a "maximum error" like ntpd does?
  - From: Abis BIso
- Re: [chrony-users] Re: Why doesn't chrony provide a "maximum error" like ntpd does?
  - From: Bill Unruh
Messages sorted by: [ date | thread ]
Prev by Date: Re: [chrony-users] Re: Why doesn't chrony provide a "maximum error" like ntpd does?
Next by Date: [chrony-users] Minimal online duration
Previous by thread: Re: [chrony-users] Re: Why doesn't chrony provide a "maximum error" like ntpd does?
Next by thread: [chrony-users] Minimal online duration
Mail converted by MHonArc 2.6.19+
http://listengine.tuxfamily.org/