Re: [chrony-users] Automotive usage of chronyd

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


Configuration.

makestep and initstepslew. The latter is for network sources. The former is
also for refclocks.
Probably makestep would be best for your purposes.

"   An example of the use of this directive is

     makestep 1000 10

        This would step system clock if the adjustment is larger than 1000
	seconds, but only in the first ten clock updates.
"



On Sun, 5 Apr 2015, Olivier Delbeke wrote:

Hi Bill,

Thanks a lot. I will dig into the code and try to understand exactly what happens
and how I could use chronyd in the best possible way. Then, I will propose it to
AGL.

Also read the documentation :-)

You said ""But yes, you can tell it to jump the clock if it is far off initially (or
at any time) rather than slewing"" Do you know how to do that ? Is it a
configuration option or do you mean changing the code ? Maybe I should just look at
how chronyc does that.

Happy Easter,
Olivier


On Sat, Apr 4, 2015 at 8:36 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:

      On Sat, 4 Apr 2015, Bill Unruh wrote:


            On Sat, 4 Apr 2015, Olivier Delbeke wrote:

      ....

                  I made a first test in a near worst-case
                  scenario : system without RTC and without
                  network,
                  but with only a USB GPS sensor (without PPS).
                  Time/date after boot is Jan 1, 1970, 00:00:00.
                  I send the timestamps of the GPS sensor to
                  chronyd (over a socket), but chronyd rejects
                  them. Even if I use the first GPS timestamp to
                  force the system time, the subsequent
                  timestamps are still rejected by chronyd
                  ("refclock sample not valid age=-0.41" from
                  refclock.c - valid_sample_time())). What is the
                  condition for a valid sample ? I can
                  understand that samples are rejected, but the "<
                  0.0" conditions looks like the drift is
                  only allowed in one direction. Is that right ?


            Well, time does only flow in one direction. Why would the
            next sample be
            earlier than the first from a GPS? GPS time is
            unidirectional.


      I suppose what could be happening is that chrony is picking up the the
      first
      report very late and that you have a time offset on the pulses, so the
      first
      pulse time  being read by chrony just before the next time comes in. It
      might
      be an idea to discard the very first pulse time, and start with the
      second
      one.


                  Thank you very much,

                  Olivier




            --
            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.





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