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 <un...@physics.ubc.ca> wrote: > > Return-Path: <listmas...@tuxfamily.org> > 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.b...@gmx.com>; 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 <listmas...@tuxfamily.org>) > id 1ejqWo-00021Z-4T > for abis.b...@gmx.com; 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 <un...@physics.ubc.ca>) id > 1ejqWe-00021I-V3 for chrony-users@chrony.tuxfamily.org; 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 <un...@physics.ubc.ca> > To: chrony-users@chrony.tuxfamily.org > Subject: Re: [chrony-users] Re: Why doesn't chrony provide a "maximum > error" like ntpd does? > In-Reply-To: <1518111322.1878...@smtp.gmx.com> > Message-ID: <alpine.lmd.2.03.1802080956320.8...@physics.ubc.ca> > References: <1518071952.388...@smtp.gmx.com> > <alpine.lmd.2.03.1802080921350.2...@physics.ubc.ca> > <1518111322.1878...@smtp.gmx.com> > 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-requ...@chrony.tuxfamily.org?subject=unsubscribe> > List-Subscribe: > <mailto:chrony-users-requ...@chrony.tuxfamily.org?subject=subscribe> > List-Help: <mailto:chrony-users-requ...@chrony.tuxfamily.org?subject=help> > List-Software: Listengine, VHFFS 4.7-dev-2b25a01d00 > List-ID: <chrony-users.chrony.tuxfamily.org> > List-Post: <mailto:chrony-users@chrony.tuxfamily.org> > List-Archive: > <http://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-users> > Precedence: list > Reply-To: chrony-users@chrony.tuxfamily.org > Envelope-To: <abis.b...@gmx.com> > 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 |____ un...@physics.ubc.ca > 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 <un...@physics.ubc.ca> 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 |____ un...@physics.ubc.ca >>> 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-requ...@chrony.tuxfamily.org with >>>> "unsubscribe" in the subject. >>>> For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in >>>> the subject. >>>> Trouble? Email listmas...@chrony.tuxfamily.org. >>> -- >>> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with >>> "unsubscribe" in the subject. >>> For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the >>> subject. >>> Trouble? Email listmas...@chrony.tuxfamily.org. >> >> >> >> >> >> -- >> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with >> "unsubscribe" in the subject. >> For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the >> subject. >> Trouble? Email listmas...@chrony.tuxfamily.org. >> > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with > "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the > subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > > > > 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 |____ un...@physics.ubc.ca > 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 <un...@physics.ubc.ca> 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 |____ un...@physics.ubc.ca >>> 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-requ...@chrony.tuxfamily.org with >>>> "unsubscribe" in the subject. >>>> For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in >>>> the subject. >>>> Trouble? Email listmas...@chrony.tuxfamily.org. >>> -- >>> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with >>> "unsubscribe" in the subject. >>> For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the >>> subject. >>> Trouble? Email listmas...@chrony.tuxfamily.org. >> >> >> >> >> >> -- >> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with >> "unsubscribe" in the subject. >> For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the >> subject. >> Trouble? Email listmas...@chrony.tuxfamily.org. >> > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with > "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the > subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.