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

Actually, FYI, from the chrony docs:

broadcast interval address [port]

The broadcast directive is used to declare a broadcast address to which chronyd should send packets in the NTP broadcast mode (i.e. make chronyd act as a broadcast server). Broadcast clients on that subnet will be able to synchronise.

chronyd itself cannot act as a broadcast client; it must always be configured as a point-to-point client by defining specific NTP servers and peers. This broadcast server feature is intended for providing a time source to other NTP implementations.

If ntpd is used as the broadcast client, it will try to measure the round-trip delay between the server and client with normal client mode packets. Thus, the broadcast subnet should also be the subject of an allow directive.

I think the terminology can be misinterpreted here (by a newbie like me).. A "broadcast client" is an NTP server listening for NTP broadcasts, not sending them. And chrony can't be a "broadcast client". e.g. listen for NTP broadcasts. So (maybe I misinterpreted your suggestion) I could reverse the situation and have chrony forward/broadcast over the one-way link to an ntpd server. I was hoping to use chrony on the destination server to control updating the system time.

Either way its a possibility. I would have to switch to ntpd on the other destination server. Thanks for the suggestion!

-Chris

On Thu, Sep 2, 2021 at 8:40 AM Chris McKenzie <mckenzie.c@xxxxxxxxx> wrote:

Thanks for the suggestion! I wish I had thought to look at ntpd broadcast. I was fixated on chrony and simply searching for just chrony and broadcasting didn't clue me in. I wound up with gpsd descriptions and moved to using SOCK. I'll give it a try this weekend and compare.

-Chris

On Thu, Sep 2, 2021 at 8:09 AM <frank.villaro@xxxxxxxxxxxxxx> wrote:
Hi,

Why don't you use NTP in broadcast mode ? It would work on an (ethernet, or something else) one-way link/data diode and the big plus is that everything is already implemented (chrony as server and ntpd as client).

Cheers
Le 2021-09-01T21:06:16.000+02:00, Chris McKenzie <mckenzie.c@xxxxxxxxx> a écrit :
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.

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

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.

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