Hi,

  I am looking for the best single indicator that can be used to
  determine/monitor the current clock accuracy.

  I have several remote/embedded Linux devices that I am monitoring
  via SNMP and want to monitor a single variable to know how accurate
  the device thinks its time is.

  There seems to be several possibilities:
    - delay or offset or jitter (from ntpq -clpeers)
    - sync distance (from ntptrace)
    - maximum error (from ntpdc)
    - precision (from ntpq -crl)
    - ?

  Below is the output of several NTP status monitoring commands...


# ntpq -clpeers
     remote           refid      st t when poll reach   delay
offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.          10 l   43   64  377    0.000
0.000   0.015
*GPS_NMEA(0)     .MAL.            0 l    4   16  377    0.000
0.156   0.015
+ntp-2.gw.uiuc.e 128.118.25.5     2 u   41   64  377   71.652
2.432   0.528
+ntp-1.gw.uiuc.e 128.174.38.133   2 u   21   64  377   72.009
2.373   1.389


# ntptrace
localhost: stratum 1, offset 0.000159, synch distance 0.000539, refid
'MAL'


# ntpdc -c kerninfo 127.0.0.1
pll offset:           0.000151 s
pll frequency:        -27.934 ppm
maximum error:        0.007856 s
estimated error:      1.5e-05 s
status:               0001  pll
pll time constant:    4
precision:            1e-06 s
frequency tolerance:  512 ppm

# ntpq -crl
assID=0 status=04f4 leap_none, sync_uhf_clock, 15 events, event_peer/
strat_chg,
version="ntpd 4.2.2p4@1.1585-o Fri Jun 15 10:17:41 UTC 2007 (1)",
processor="i486", system="Linux/2.6.21-tinytgb5-pc", leap=00,
stratum=1,
precision=-16, rootdelay=0.000, rootdispersion=0.393, peer=56438,
refid=MAL, reftime=cecbd50a.91b1b70c  Thu, Dec 10 2009 12:14:02.569,
poll=10, clock=cecbd50f.302c13d6  Thu, Dec 10 2009 12:14:07.188,
state=4, offset=0.057, frequency=-27.993, jitter=0.015, noise=0.015,
stability=0.000, tai=0


Thanks,
Kert

kjans wrote:
> 
>   I have several remote/embedded Linux devices that I am monitoring
>   via SNMP and want to monitor a single variable to know how accurate
>   the device thinks its time is.

The device doesn't think much about how accurate it is, only about how 
repeatable.

> 
>   There seems to be several possibilities:
>     - delay or offset or jitter (from ntpq -clpeers)

Offset is useless in isolation, as you may measure an outlyer.  Delay is 
only one hop, and represents a worst case factor.  Jitter maybe, but 
only if it is the dominant error term for your particular system.

>     - sync distance (from ntptrace)

Gives you a near worst case figure, most of the time.

>     - maximum error (from ntpdc)

Another attempt at worst case.

>     - precision (from ntpq -crl)

Characteristic of the hardware/OS, not of the actual current time quality.

>     - ?
> 
>   Below is the output of several NTP status monitoring commands...
> 
> 
> # ntpq -clpeers
>      remote           refid      st t when poll reach   delay
> offset  jitter
> ==============================================================================
>  LOCAL(0)        .LOCL.          10 l   43   64  377    0.000
> 0.000   0.015

(Should never be used on leaf nodes)

> *GPS_NMEA(0)     .MAL.            0 l    4   16  377    0.000
> 0.156   0.015
> +ntp-2.gw.uiuc.e 128.118.25.5     2 u   41   64  377   71.652
> 2.432   0.528
> +ntp-1.gw.uiuc.e 128.174.38.133   2 u   21   64  377   72.009
> 2.373   1.389

> pll frequency:        -27.934 ppm
> maximum error:        0.007856 s
> estimated error:      1.5e-05 s

This is probably the most useful single figure.

However, all except the ones I describe as maximum tell you about 
repeatability, not error. E.g. if you are only using NMEA, and not PPS, 
the error could be up to about a second, but, if only one sort of 
sentence is coming from the GPS, you might have repeatability down in 
the 15 microsecond range that these figures are suggesting.  (The other 
figures suggest that the overall error is no more than tens of ms.)

> status:               0001  pll
> pll time constant:    4
> precision:            1e-06 s
> frequency tolerance:  512 ppm
> 

What confidence level do you need in the error bounds?

On 2009-12-10, kjans <kert.jans@gmail.com> wrote:
> Hi,
>
>   I am looking for the best single indicator that can be used to
>   determine/monitor the current clock accuracy.
>
>   I have several remote/embedded Linux devices that I am monitoring
>   via SNMP and want to monitor a single variable to know how accurate
>   the device thinks its time is.
>
>   There seems to be several possibilities:
>     - delay or offset or jitter (from ntpq -clpeers)
>     - sync distance (from ntptrace)
>     - maximum error (from ntpdc)
>     - precision (from ntpq -crl)
>     - ?

Offset. That is ntp's best guess as to the difference between the time
on your clock and the true UTC time. ntp keeps no record of the rate
error, or any other error. The jitter is how much teh offset fluctuates
so is a measure of how bad things are on average, delay is useless since
all it tells you is how far away your time source is. 
>

unruh wrote:
> On 2009-12-10, kjans <kert.jans@gmail.com> wrote:
>>   I am looking for the best single indicator that can be used to
>>   determine/monitor the current clock accuracy.
> Offset. That is ntp's best guess as to the difference
>  between the time on your clock and the true UTC time.

AFAICT

ntpq -c rv gets the system variables, among them is a combined
 offset (ms) from the selected truechimer peers reference times,
 (or the offset from the preferred peer).
 e.g. ntpq -c rv ... offset=-5.515 ...

ntpdc -c loopinfo will also get that offset in a different format.
 e.g. ntpdc -c loopinfo offset:               -0.005515 s ...


The Root Dispersion to the primary reference clock (stratum 1),
 would be "the difference between the time on your clock and
 the true UTC time" (ms)
 e.g. ntpq -c rv ... rootdisp=56.621 ...
  {with GPS/PPS, root dispersion will likely be 5. or less.}


<http://alumni.media.mit.edu/~nelson/research/ntp-survey99/html/>
"dispersion of that root time: these measurements are useful
  for determining the final accuracy of a host's clock"

-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.

On 2009-12-11, E-Mail Sent to this address will be added to the BlackLists <Null@BlackList.Anitech-Systems.invalid> wrote:
> unruh wrote:
>> On 2009-12-10, kjans <kert.jans@gmail.com> wrote:
>>>   I am looking for the best single indicator that can be used to
>>>   determine/monitor the current clock accuracy.
>> Offset. That is ntp's best guess as to the difference
>>  between the time on your clock and the true UTC time.
>
> AFAICT
>
> ntpq -c rv gets the system variables, among them is a combined
>  offset (ms) from the selected truechimer peers reference times,
>  (or the offset from the preferred peer).
>  e.g. ntpq -c rv ... offset=-5.515 ...
>
> ntpdc -c loopinfo will also get that offset in a different format.
>  e.g. ntpdc -c loopinfo offset:               -0.005515 s ...
>
>
> The Root Dispersion to the primary reference clock (stratum 1),
>  would be "the difference between the time on your clock and
>  the true UTC time" (ms)
>  e.g. ntpq -c rv ... rootdisp=56.621 ...
>   {with GPS/PPS, root dispersion will likely be 5. or less.}

The root dispersion is an estimate of the error in the remote clock's time. It is not an
estimate of the difference in time between your clock and the true time.
Add to the root dispersion half the round trip time to get the max error
in your clock. 

The best estimate of the difference between your clock time and the true
time is the offset. It is designed to be the best estimate. The max
error in that time is given by the root dispersion of the soruce plus half the offset. 


>
>
><http://alumni.media.mit.edu/~nelson/research/ntp-survey99/html/>
> "dispersion of that root time: these measurements are useful
>   for determining the final accuracy of a host's clock"
>

unruh wrote:

> 
> Offset. That is ntp's best guess as to the difference between the time
> on your clock and the true UTC time. ntp keeps no record of the rate

No.  It is the difference between the time on your clock and the last 
measurement from other clocks.  It includes the instantaneous 
measurement error, but not systematic measurement error.  When ntpd is 
operating in a stable environment and locked onto its sources, the 
instantaneous offset readings can vary widely and the RMS value will be 
quite a bit larger than the RMS variation in error in the actual machine 
clock.

The big argument is about how often ntpd is actually operating in a 
stable environment. When it is out of lock, offset approximates the 
short term part of the error, but still does not include the systematic 
error.

unruh wrote:

> The root dispersion is an estimate of the error in the remote clock's time. It is not an
> estimate of the difference in time between your clock and the true time.

Although it contains some terms that relate to errors in remote clocks, 
its main component is an estimate of the worst case error in the local 
clock due to worst case frequency errors, assuming evary ntpd is 
actually locked on, between the time the stratum zero clock was read and 
the time that you looked at the statistics on the local machine.  The 
drift calculation potentially uses the drift rate on the machine holding 
the time at the time of the drift, although normally all ntpd's use the 
same rate.

Note, to get the full benefit of this, you need to read the root 
dispersion reported in response to time requests.  I think the value 
given in the statistics doesn't include the component due to the local 
machine.

unruh wrote:
> The root dispersion is an estimate of the error in the remote
>  clock's time.

Only if you query the NTP server your NTP is peered with,
 instead of querying your NTP server.


> It is not an estimate of the difference in time between
>  your clock and the true time.

References?

I contend root dispersion is, the diff to UTC.


> The best estimate of the difference between your clock
>  time and the true time is the offset.

References?

I contend it is not.

 That only gets you the diff to the NTP server(s) your NTP
  server is syncing to.  Not the diff to UTC.


>> <http://alumni.media.mit.edu/~nelson/research/ntp-survey99/html/>
>> "dispersion of that root time: these measurements are useful
>>   for determining the final accuracy of a host's clock"

-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.

On 2009-12-11, David Woolley <david@ex.djwhome.demon.invalid> wrote:
> unruh wrote:
>
>> 
>> Offset. That is ntp's best guess as to the difference between the time
>> on your clock and the true UTC time. ntp keeps no record of the rate
>
> No.  It is the difference between the time on your clock and the last 
> measurement from other clocks.  It includes the instantaneous 
> measurement error, but not systematic measurement error.  When ntpd is 
> operating in a stable environment and locked onto its sources, the 
> instantaneous offset readings can vary widely and the RMS value will be 
> quite a bit larger than the RMS variation in error in the actual machine 
> clock.

He asked for the best estimator of difference. And the measured offset
is it. Yes, there are sources of error, and you cannot know that those
have not affected your time, but if asked what is the difference in time
between your system and the remote system, that measured offset, using
the ntp protocol, is the best estimator of that difference. You have
nothing else from ntp. Now, one could argue that the approach used by
chrony-- doing a linear fit to the the past number of offset
measurements is a better estimator, and I would agree. But that is NOT
how ntp works. The only estimator it has is that offset, and it is thus
the best estimator.


>
> The big argument is about how often ntpd is actually operating in a 
> stable environment. When it is out of lock, offset approximates the 
> short term part of the error, but still does not include the systematic 
> error.

Agreed. But it is the only estimator you have. You might want more, but
ntp does not give it to you. 

E-Mail Sent to this address will be added to the BlackLists wrote:

> 
> I contend root dispersion is, the diff to UTC.

Root dispersion approximates the difference from UTC if ntpd's solution 
for the clock frequency is out by exactly 15ppm.  Generally the 
frequency solution is much better than that, and most of the time better 
than 0.1ppm.

(UTC means stratum 0 time here, even if that is not actually UTC.)

David Woolley wrote:
> BlackLists wrote:
>> I contend root dispersion is, the diff to UTC.
> 
> Root dispersion approximates the difference from UTC if
>  ntpd's solution for the clock frequency is out by
>  exactly 15ppm.  Generally the frequency solution is
>  much better than that, and most of the time better
>  than 0.1ppm.
> 
> (UTC means stratum 0 time here, even if that is not actually UTC.)

Yes, I was unclear, I meant it as it is documented,
 and estimate.

 Still far closer than offset, if not syncing to
  e.g. GPS/PPS locally

-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.

On 2009-12-11, E-Mail Sent to this address will be added to the BlackLists <Null@BlackList.Anitech-Systems.invalid> wrote:
> unruh wrote:
>> The root dispersion is an estimate of the error in the remote
>>  clock's time.
>
> Only if you query the NTP server your NTP is peered with,
>  instead of querying your NTP server.
>
>
>> It is not an estimate of the difference in time between
>>  your clock and the true time.
>
> References?
>
> I contend root dispersion is, the diff to UTC.

It is were the difference to UTC then ntp would use it, rather than the
offset to discipline the clock. It is clearly stupid to use something
which is a bad estimate of the difference from true time to discipline
the clock. 


>
>
>> The best estimate of the difference between your clock
>>  time and the true time is the offset.
>
> References?
>
> I contend it is not.
>
>  That only gets you the diff to the NTP server(s) your NTP
>   server is syncing to.  Not the diff to UTC.

And unfortunately that is the best estimate you have. since the server
has no estimate of its offset from true time, neither do you. 

It has an estimate of the error from true time, but that is a) a very
conservative ( ie large) estimate, and b) you have no idea where in that
range from - to + the discrepancy lies. 

>
>
>>> <http://alumni.media.mit.edu/~nelson/research/ntp-survey99/html/>
>>> "dispersion of that root time: these measurements are useful
>>>   for determining the final accuracy of a host's clock"
>

It is good for estimating the accuracy, but not the offset. 

unruh wrote:
> It is good for estimating the accuracy, but not the offset.

Isn't that what the OP asked for?

Subject: Single best NTP status indicator of clock accuracy?

  "I have several remote/embedded Linux devices that I am
    monitoring via SNMP and want to monitor a single
    variable to know how accurate the device thinks its
    time is."

-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.

kjans <kert.jans@gmail.com> writes:

> Hi,
>
>   I am looking for the best single indicator that can be used to
>   determine/monitor the current clock accuracy.

"Best and single" seem to contradict. What about "root dispersion"? ;-)

>
>   I have several remote/embedded Linux devices that I am monitoring
>   via SNMP and want to monitor a single variable to know how accurate
>   the device thinks its time is.
>
>   There seems to be several possibilities:
>     - delay or offset or jitter (from ntpq -clpeers)
>     - sync distance (from ntptrace)
>     - maximum error (from ntpdc)

estimated error, maybe.

>     - precision (from ntpq -crl)

That's a constant.

>     - ?
>
>   Below is the output of several NTP status monitoring commands...
>
>
> # ntpq -clpeers
>      remote           refid      st t when poll reach   delay
> offset  jitter
> ==============================================================================
>  LOCAL(0)        .LOCL.          10 l   43   64  377    0.000
> 0.000   0.015
> *GPS_NMEA(0)     .MAL.            0 l    4   16  377    0.000
> 0.156   0.015
> +ntp-2.gw.uiuc.e 128.118.25.5     2 u   41   64  377   71.652
> 2.432   0.528
> +ntp-1.gw.uiuc.e 128.174.38.133   2 u   21   64  377   72.009
> 2.373   1.389
>
>
> # ntptrace
> localhost: stratum 1, offset 0.000159, synch distance 0.000539, refid
> 'MAL'
>
>
> # ntpdc -c kerninfo 127.0.0.1
> pll offset:           0.000151 s
> pll frequency:        -27.934 ppm
> maximum error:        0.007856 s
> estimated error:      1.5e-05 s
> status:               0001  pll
> pll time constant:    4
> precision:            1e-06 s
> frequency tolerance:  512 ppm
>
> # ntpq -crl
> assID=0 status=04f4 leap_none, sync_uhf_clock, 15 events, event_peer/
> strat_chg,
> version="ntpd 4.2.2p4@1.1585-o Fri Jun 15 10:17:41 UTC 2007 (1)",
> processor="i486", system="Linux/2.6.21-tinytgb5-pc", leap=00,
> stratum=1,
> precision=-16, rootdelay=0.000, rootdispersion=0.393, peer=56438,
> refid=MAL, reftime=cecbd50a.91b1b70c  Thu, Dec 10 2009 12:14:02.569,
> poll=10, clock=cecbd50f.302c13d6  Thu, Dec 10 2009 12:14:07.188,
> state=4, offset=0.057, frequency=-27.993, jitter=0.015, noise=0.015,
> stability=0.000, tai=0
>
>
> Thanks,
> Kert

This thread has been dormant for more than 7 months!

Ulrich Windl wrote:
> kjans <kert.jans@gmail.com> writes:
>>
>>   There seems to be several possibilities:
>>     - delay or offset or jitter (from ntpq -clpeers)

Does not include systematic error.

>>     - sync distance (from ntptrace)

Extremely pessimistic.

>>     - maximum error (from ntpdc)

Also pessimistic.

> 
> estimated error, maybe.

I don't think that includes systematic error due to asymmetry.  It's 
basically impossible to get a reasonable estimate of that component 
without detailed knowledge of the environment.

> 
>>     - precision (from ntpq -crl)

Characteristic of the hardware/OS and EXTREMELY optimistic as estimate 
of error.
> 
> That's a constant.

And that as well.