Re: [chrony-users] Timeout for initstepslew?

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]



On Tue, 24 Sep 2019, Zack Shivers wrote:

Going back to my terminology, host1 is the NTP server, host2 is the NTP client. My understanding is that host1's clock will not change in
response to anything in host2 since there is a unidirectional relationship between server and client. There can be no feedback loop if this is
true.

I agree. But that also means that host2 will be slaved to host1 and if host1
goes wandering off for some reason, host 2 will try to follow.

chrony does better than ntpd at trying to smooth out the response because of
its fitting proceedure. The filter is for refclocks and is a "median" filter in which
the stuff which is more than 1 standard devation away from the mean is thrown
away. This is to try to get rid of "popcorn" noise.
You are not using a refclock. Maybe you should us for example a gps timing receiver which one or both
systems could use to discipline themselves to UTC.-- if both are slaved to
utc, they are also slaved to each other.


Could I gain the accuracy of shorter polling interval with added rate stability by using the filter option? If so, do you have any recommended
values for poll and filter?



On Tue, Sep 24, 2019 at 12:10 PM Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
      Actually setting a high poll rate does not necessarily get you a better sync.
      It determines the offset more "accurately" but determines the rate worse. Ie,
      if clock A gets its time from clock B, then the rate of A will jump around
      much more if the poll interval is shorter. Now you may not care about the
      clock rate, in which case short poll intervals are better, but that would also
      mean that time differences would be much more random. Also if you lose clock
      B, then clock A will drift away from the "correct" time much more rapidly.

      Also, if in the short term, clock B say heats up (due to some program running
      on B) A will try to follow that change in timing on the short term.

      Ie, you need to think carefully about what you want from your clocks, before
      you simply say "shorter poll intervals are better".

      You could also set up a polling of the computer running B and only start
      chronyon A when B actually comes up.

      What do you use for timing clock B? If B uses A as its source and A uses B,
      you can get problems with runaway behaviour. B tells A to speed up. A then
      tells B to speed up, and way they go.


      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 Tue, 24 Sep 2019, Zack Shivers wrote:

      > Good to know these are equivalent!
      >
      > If I used this config, it will permanently set the poll rates for this
      > server, correct? Since this is a local setup, I'm using a high poll
      > rate (-3) to get a better sync. Setting the timeout as a function of
      > the poll rate is not ideal.
      >
      >
      >
      > On Tue, Sep 24, 2019 at 12:55 AM Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
      >>
      >> On Mon, Sep 23, 2019 at 05:20:12PM -0700, Zack Shivers wrote:
      >>> I ask about the timeout on initstepslew is that the problem would be
      >>> solved if I could set a much longer timeout than 10 seconds. The
      >>> makestep option could work instead, but I've seen issues using this as
      >>> well that I will post about later.
      >>
      >> initstepslew is basically the same as a "server ... iburst" and
      >> "makestep" together. iburst in initstepslew will send up to 6 requests
      >> in 2 second interval, which is about 10 second total. If you need to
      >> send more requests and keep the short interval, you could use the minpoll
      >> and maxpoll options instead of iburst. For example:
      >>
      >> server host1 minpoll 1 maxpoll 1
      >> makestep 0.1 3
      >>
      >> Please let us know what are the issues with this approach.
      >>
      >> --
      >> Miroslav Lichvar
      >>
      >> --
      >> 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.
      >>
      >
      >
      > --
      >
      > Zack Shivers
      > Electrical / Embedded Systems Engineer
      >
      > --
      > 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.



--
[uc?export=download&id=1wJzXSPmoblt1ldX71DDy4ceY-cHDQ-pa&revid=0B8gashE-Q-zgRi9zVElXTUNZRHhGWlczci9TdE5tMXN1K2hrPQ]
Zack Shivers
Electrical / Embedded Systems Engineer



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/