| Re: [chrony-users] Understanding Chrony SOCK time sample "not valid age" |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
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