Re: [chrony-users] Automotive usage of chronyd

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

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.