Re: [chrony-users] Understanding Chrony SOCK time sample "not valid age"

[ Thread Index | Date Index | More Archives ]

Thanks Miroslav.

The time sample source is from a different PC that has the correct/accurate time (it has a good NTP source). The "not valid age" is on a 2nd PC (the reasons I have to do this whole thing have been mentioned, just assume this is the only time source) when that time sample is pushed to the 2nd PC Chrony SOCK. From what I understand the difference between the 2nd PC local system time and the received time sample is what I want Chrony to adjust. e.g. the 2nd PC has drifted or is just off, and the time sample is to help Chrony get it in sync with the 1st PC (in a graceful way). 

I checked again and to me (please correct me if I'm wrong) the Chrony SOCK support is to allow for an alternative reference clock to feed time samples into it. It's completely natural for the refclock to be different from the local system time. The refclock_sock.c struct describes the time message format, and timeval is the system time of the source, being fed into Chrony. If this is correct (seriously I apologize if I'm completely missing the point here, I've been reading and re-reading the Chrony docs) then I should be using it correctly, BUT maybe my understanding of this use case isn't correct.

I just realized something. The makestep directive mentions that initstepskew is not supported in non-NTP sources. In the initstepskew directive the following is described (I didn't think to read it before, as I wasn't using initstepskew):

"In normal operation, chronyd slews the time when it needs to adjust the system clock. For example, to correct a system clock which is 1 second slow, chronyd slightly increases the amount by which the system clock is advanced on each clock interrupt, until the error is removed. Note that at no time does time run backwards with this method."

So I think I'm now clear on what was happening and why "not valid age" is the correct behavior. I assumed I was using it wrong, but if my source clock is behind the receiving PC, Chrony will not move the clock back in time. Only step is forward/faster, and this support is meant to keep a clock accurate, not jump days/hours to fix a completely incorrect clock time.

Sorry if this was obvious and I didn't pick up on it. I was tasked with trying to sync 2 PCs over this one-way optical link and the limitations were that the destination server would have no Internet, no NTP, no GPS. Like a black box/hole. I decided to go with Chrony SOCK because of your graceful handling of time sync from refclock samples. I figured if the world uses Chrony, I should too..

Please let me know if this is a correct understanding. Thank you so much for replying!


On Thu, Sep 2, 2021 at 2:22 AM Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
On Wed, Sep 01, 2021 at 03:06:16PM -0400, Chris McKenzie wrote:
> What this suggests is a time sample containing a time *ahead* of the
> receiving chrony server time will be rejected.
> I must be misunderstanding the situation or what time samples are
> completely. It makes no sense to me that a time sample sent to a chrony
> service that is 4 seconds ahead would reject the time, since its job is to
> sync time with/from a source (ahead or behind).

The sample time is the local system time when the sample was made. If
it is ahead of the current system time, it's clearly invalid. It
cannot be from the future from the system clock's point of view.

In terms of a C code, the sample time should be filled by
gettimeofday() when the reference time is received. The offset is the
difference between the sample time and the reference time. That would
be those 4 seconds in your test.

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.

Mail converted by MHonArc 2.6.19+