On 2016-09-20 04:49, sneha b wrote:

Is there a way to find out whether the sync was successful or not.
In vxworks we have ipsntp_query_time, is there something similar to this so
that I can use it programmatically and return success/failure.


NTP does not sync time (except perhaps at startup), it disciplines time within
128ms limits, normally within ms to us, so it depends on the configuration and
setup of your reference clocks, servers and daemons, availability and quality
of your network connections and timing sources, and your requirements:
are offsets of a few us required, or are a few ms okay; how much variance and
error is acceptable over what period of time, or during your critical times?

e.g.

$ ntpq -p -c rv
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPS.            0 l    9   16  377    0.000    0.002   0.002
+............... .GPS.            1 s   11   16  376    1.179    0.206   1.977
+utcnist2.colora .NIST.           1 u   43   64  377   64.869    2.672  97.821
-montpelier.ilan .GPS.            1 u    2   64  377   71.785    9.453  86.028
-tick.ucla.edu   .GPS.            1 u   48   64  337   71.649    9.634  69.159
...
associd=0 status=0419 leap_none, sync_uhf_radio, 1 event, leap_armed,
...
precision=-20, rootdelay=0.000, rootdisp=0.372, refid=GPS,
...
mintc=3, offset=0.002, frequency=-5.532, sys_jitter=0.002,
clk_jitter=0.000, clk_wander=0.001, ...

where:
poll            time between source queries (s in ntpq, log2 s in conf)
reach           whether the source responded in the last 8 polls (bits in octal)
delay           time between sending query and receiving response (ms in ntpq)
offset          source time + delay/2 - system time (ms in ntpq)
jitter          variation in offset (ms in ntpq)
precision       time to read the system clock (log2 s)
drift           system clock estimated *frequency* drift (PPM, us/s)
wander          variation in frequency drift (PPM, us/s)
disp            dispersion - offset maximum error

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to