Re: [chrony-users] Automotive usage of chronyd

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

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@chrony.tuxfamily.org with "unsubscribe"
in the subject.
For help email chrony-users-request@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmaster@chrony.tuxfamily.org.

--
To unsubscribe email chrony-users-request@chrony.tuxfamily.org with
"unsubscribe" in the subject.
For help email chrony-users-request@chrony.tuxfamily.org with "help" in
the subject.
Trouble? Email listmaster@chrony.tuxfamily.org.