clock_error <= |system_time_offset| + root_dispersion + (0.5 * root_delay)
Reference ID : 50505300 (PPS) Stratum : 1 Ref time (UTC) : Sat Dec 21 17:18:57 2024 System time : 0.000000106 seconds slow of NTP time Last offset : -0.000000096 seconds RMS offset : 0.000000172 seconds Frequency : 0.569 ppm fast Residual freq : -0.000 ppm Skew : 0.005 ppm Root delay : 0.000000001 seconds Root dispersion : 0.000017795 seconds Update interval : 16.0 seconds Leap status : Normal
Explanation:
This is near-real-time live output of the 'chronyc tracking' command that lists the state of my time server.
This is the reference ID and name (or IP address) of the server to which the computer is currently synchronised. For my stratum-1 time server, the ID is normally "50505300 (PPS)", indicating the server is synchronized with the Pulse Per Second (PPS) output of the local GPS. If something else appears here, it could mean the GPS has lost signal for some reason, and we are falling back to a different time source.
The stratum indicates how many hops away from a computer with an attached reference clock we are. This server is normally syncronized with its local GPS unit, so we are normally "Stratum 1". If our local GPS unit had failed, and we were synchronised to a Stratum 1 server on the net, we would be Stratum 2. If we were synchronized to a Stratum 2 server, we would be Stratum 3, etc.
This is the time (UTC) at which the last measurement from the reference source was processed. It's typically several seconds earlier than the time listed at the very top of this page, when we ran the "chronyc tracking" command.
In normal operation, chronyd by default never steps the system clock, because any jump in the time can have adverse consequences for certain application programs. Instead, any error in the system clock is corrected by slightly speeding up or slowing down the system clock until the error has been removed, and then returning to the system clock’s normal speed. A consequence of this is that there will be a period when the system clock (as read by other programs) will be different from chronyd's estimate of the current true time (which it reports to NTP clients when it is operating in server mode). The value reported on this line is the difference due to this effect.
This is the estimated local offset on the last clock update. It is shown with
nine digits after the decimal point. The last three digits are the number of
nanoseconds of offset. For example, if the last offset is shown as +0.000000123 seconds
, that means the estimated local offset is 123 nanoseconds. To give some context, light travels at approximately one foot (0.3 m) per nanosecond, so 100 nanoseconds is the time it takes light to
travel roughly a third of the length of a football field.
This is a long-term average of the offset value.
The ‘frequency’ is the rate by which the system’s clock would be wrong if chronyd was not correcting it. It is expressed in ppm (parts per million). For example, a value of 1 ppm would mean that when the system’s clock thinks it has advanced 1 second, it has actually advanced by 1.000001 seconds relative to true time.
This shows the ‘residual frequency’ for the currently selected reference source. This reflects any difference between what the measurements from the reference source indicate the frequency should be and the frequency currently being used.
The reason this is not always zero is that a smoothing procedure is applied to the frequency. Each time a measurement from the reference source is obtained and a new residual frequency computed, the estimated accuracy of this residual is compared with the estimated accuracy (see ‘skew’ next) of the existing frequency value. A weighted average is computed for the new frequency, with weights depending on these accuracies. If the measurements from the reference source follow a consistent trend, the residual will be driven to zero over time.
This is the estimated error bound on the frequency.
This would be the total of the network path delays to the stratum-1 computer from which the computer is ultimately synchronised. When we are synchronized using our local GPS unit, this is normally just shown as one nanosecond.
This is the total dispersion accumulated through all the computers back to the stratum-1 computer from which the computer is ultimately synchronised. Dispersion is due to system clock resolution, statistical measurement variations, etc.
An absolute bound on the computer’s clock accuracy (assuming the stratum-1 computer is correct) is given by:
clock_error <= |system_time_offset| + root_dispersion + (0.5 * root_delay)
This is the interval between the last two clock updates.
This is the leap status, which can be Normal, Insert second, Delete second or Not synchronised.
The output at the top of the page is generated in near real time. Refresh the page to see the numbers update a little bit.