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

Thanks for the helpful feedback Bill.

I can't really get a GPS source in a concrete basement lab and I can't forward NTP over a one way link, and the time sample from the source server my client is running on is sync'd via NTP and chrony. Which is why I'm even bothering with SOCK support. Regarding validation, maybe you didn't read the part where I included the actual code that Chrony uses to validate time samples from a SOCK source. So I'm pretty sure I applied the term correctly here.

static int

valid_sample_time(RCL_Instance instance, struct timespec *sample_time)
{
struct timespec now;
double diff;

LCL_ReadCookedTime(&now, NULL);
diff = UTI_DiffTimespecsToDouble(&now, sample_time);

if (diff < 0.0 || diff > UTI_Log2ToDouble(instance->poll + 1)) {
DEBUG_LOG("%s refclock sample time %s not valid age=%.6f",
UTI_RefidToString(instance->ref_id),
UTI_TimespecToString(sample_time), diff);
return 0;
}

return 1;
}

Besides, I think I figured it out. My makestep was too small in my chrony.conf and I didn't realize it was slowly adjusting back to 0 in the chrony debug logs. The time sample is "not valid age" until its adjusted to 0. It appears the time sample that's being validated is pre-adjusted at the time the validation code runs, which was what I was trying to understand when I emailed this list.

Enjoy your afternoon Bill. I appreciate the attention.

-Chris

On Wed, Sep 1, 2021 at 3:43 PM Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:

On Wed, 1 Sep 2021, Chris McKenzie wrote:

> [CAUTION: Non-UBC Email]Hi.
> I'm new to the mailing list. I really hope I'm not doing this wrong but I
> can't seem to understand how Chrony validates refclock time samples.

What do you mean by "validates"? You choose the server which you believe has
accurate time. That of course does not mean that it cannot go crazy and start
sending back junk (ie stuff which is no longer related to current time). Which
is whyyou should have at least 3 or maybe more than that, servers, so you can
use a "majority rules" rule. (the time which a majority says is current time
is most likely, the real current time).

> I've implemented a C program running on RHEL that needs to forward time
> samples from one server to another over a one-way optical link. The time on
> the source server is a simple gettimeofday(), it's stored in a message and

Horrible source. Why would you do that. You can get a GPS clock (accurate to
nanoseconds) for about what you pay for a cup of coffee (ok, for coffee for
all of your closest friends). gettimeofday is going to give you time that is
almost certainly seconds, but may be months or millenia out.

> sent to the receiving C server program which then pushes a time sample to a
> Chrony SOCK. When I test this on my local system it works fine, but between
> the servers I receive the following debug logs (I enabled chrony debug
> logging):

Perhaps if you told us what you were trying to do, it would help. Or go read
the NTP book by DAvid Mills to understand the theory of ntp.

>
> Sep 01 01:28:31 red-node.local chronyd[14186]: 2021-09-01T01:28:31Z
> refclock.c:616:(valid_sample_time) SOCK refclock sample time
> 1630459715.587552000 not valid age=-4.064528
> Sep 01 01:29:31 red-node.local chronyd[14186]: 2021-09-01T01:29:31Z
> refclock.c:616:(valid_sample_time) SOCK refclock sample time
> 1630459775.588427000 not valid age=-4.065328
> Sep 01 01:30:31 red-node.local chronyd[14186]: 2021-09-01T01:30:31Z
> refclock.c:616:(valid_sample_time) SOCK refclock sample time
> 1630459835.588663000 not valid age=-4.065453
>
> My source server is 4 seconds ahead of the target server and I'm a bit
> confused because I want to actually have chrony gracefully bring the target
> server time (4 seconds) in line with my source server.

That was what ntp was invented for. WHy are you trying to reinvent it?

>
> There's no internet or local NTP server in this situation, so this is the
> only way I can feed time into Chrony. I could simply force the local time to
> match, but Chrony does all the graceful time adjustment stuff that I would
> never be able to get right.
>
> My /etc/chrony.conf:
>
> refclock SOCK /var/run/chrony.sock offset 0.002 delay 1e-9 refid SOCK
>
>
> I'm using the chrony refclock time sample structure as required:
>
> struct time_sample {
> /* Time of the measurement (system time) */
> struct timeval tv;
>
> /* Offset between the true time and the system time (in seconds) */
> double offset;
>
> /* Non-zero if the sample is from a PPS signal, i.e. another source
> is needed to obtain seconds */
> int pulse;
>
> /* 0 - normal, 1 - insert leap second, 2 - delete leap second */
> int leap;
>
> /* Padding, ignored */
> int _pad;
>
> /* Protocol identifier (0x534f434b) */
> int magic;
> };
>
>
> The `not valid age` is not a well documented case, but in the chrony source
> that logs that message, there's a basic time sample diff between `now` and
> the time sample where anything less than a 0.0 is invalid.
>
> ```
> static int
> valid_sample_time(RCL_Instance instance, struct timespec *sample_time)
> {
> struct timespec now;
> double diff;
>
> LCL_ReadCookedTime(&now, NULL);
> diff = UTI_DiffTimespecsToDouble(&now, sample_time);
>
> if (diff < 0.0 || diff > UTI_Log2ToDouble(instance->poll + 1)) {
> DEBUG_LOG("%s refclock sample time %s not valid age=%.6f",
> UTI_RefidToString(instance->ref_id),
> UTI_TimespecToString(sample_time), diff);
> return 0;
> }
>
> return 1;
> }
> ```
>
> 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).
>
> This also could be a SOCK only situation. If it is, please let me know.. I'll
> have to find another way to update the chrony time. Similarly if you have an
> alternative suggestion it would be helpful.
>
> Thank you!
>
> -Chris
>
>