1

I'm working on a project which will acquire a lot of timestamped data at fairly high resolution (50 samples per second) over a very long period of time (years).

The solution includes various failover mechanisms. During the lifespan of this project it's reasonable to assume that some data-loggers will need to be replaced. IE some will come online once data acquisition has already stated by others.

Given the nature of the data, it would be very bad if some data were recorded with inaccurate timestamps, even a handful of seconds out. NTP should be solid enough for this solution, and even if network is lost for a few hours the drift on the internal clock should be too small to cause a significant problem. Actually we care less about data during internet outages for esoteric reasons.

What bothers me is what happens when a data-logger is rebooted. Or booted for the first time. I want the device to reliably stabilise its system time using NTP before it meshes into the failover solution.

How can I determine the current reliability of the system time with respect to either chrony or ntpd. That is, how can I get a value from either, telling me:

  • how recently they last synchronised
  • If possible, a confidence value in the last update*

By Confidence I mean something along the lines of total round trip time of the NTP packets... which is of course part of the NTP specification.

2
  • I don't have the spec to hand but ntpq will show you when it's synchronised, also how far away from "correct" time it is. I'm away for the weekend but can look if no-one else gets there first Commented Apr 28, 2023 at 22:12
  • 1
    @roaima Oh that's interesting. Full answer definitely welcome. What's nice about ntpq, reading the manual, is that it can work remotely. That might even embed into an element of our failover logic. Commented Apr 28, 2023 at 22:21

1 Answer 1

1

I wonder whether you read about the features of NTPv3, or the meaning of chronyd's tracking output:

chronyc> tracking Reference ID : AC14100E (p22.ntp-pool.domain.org) Stratum : 3 Ref time (UTC) : Thu Nov 23 14:10:49 2023 System time : 0.000021786 seconds fast of NTP time Last offset : +0.000005573 seconds RMS offset : 0.000017535 seconds Frequency : 13.186 ppm fast Residual freq : +0.002 ppm Skew : 0.018 ppm Root delay : 0.000255787 seconds Root dispersion : 0.001269149 seconds Update interval : 64.2 seconds Leap status : Normal 

Or ntpq's rl output:

associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer, version="ntpd [email protected] Wed Jun 14 05:48:57 UTC 2023 (1)", processor="x86_64", system="Linux/4.12.14-122.179-default", leap=00, stratum=2, precision=-24, rootdelay=0.157, rootdisp=5.951, refid=172.20.2.25, reftime=e909db6b.de677ef7 Thu, Nov 23 2023 15:08:43.868, clock=e909dc91.e033d3a0 Thu, Nov 23 2023 15:13:37.875, peer=12886, tc=9, mintc=3, offset=+0.007816, frequency=+11.587, sys_jitter=0.222731, clk_jitter=0.022, clk_wander=0.004 

You could also try sysinfo and kerninfo in recent versions:

ntpq> kerninfo associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer, pll offset: 0.005928 pll frequency: 11.5873 maximum error: 284.634 estimated error: 0.022 kernel status: pll nano pll time constant: 9 precision: 1e-06 frequency tolerance: 500 pps frequency: 0 pps stability: 0 pps jitter: 0 calibration interval 0 calibration cycles: 0 jitter exceeded: 0 stability exceeded: 0 calibration errors: 0 ntpq> sysinfo associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer, system peer: 172.20.2.25:123 system peer mode: client leap indicator: 00 stratum: 2 log2 precision: -24 root delay: 0.135 root dispersion: 1.135 reference ID: 172.20.2.25 reference time: e909dd93.de684491 Thu, Nov 23 2023 15:17:55.868 system jitter: 0.251147 clock jitter: 0.027 clock wander: 0.004 broadcast delay: -50.000 symm. auth. delay: 0.018 

you might want to read in the NTP FAQ on Monitoring.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.