Re: [chrony-users] Automotive usage of chronyd

[ Thread Index | Date Index | More Archives ]


OK, thanks a lot, Bill and Tom. I will carefully read the documentation and implement some proof-of-concept this week.

Best regards,

On Sun, Apr 5, 2015 at 6:33 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:

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

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,

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

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

                  Thank you very much,


            To unsubscribe email
   with "unsubscribe"
            in the subject.
            For help email
            with "help" in the subject.
            Trouble?  Email

      To unsubscribe email with
      "unsubscribe" in the subject.
      For help email with "help" in
      the subject.
      Trouble?  Email

Mail converted by MHonArc 2.6.19+