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?
$ 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, ...
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