[ntp:questions] how to read and understand ntpq -pcrv output - pre-wiki
jim.cromie at gmail.com
Mon May 15 18:42:29 UTC 2006
in the hope that its seen as more useful, Im framing questions
in a way Id like to have found reading the wiki.
Once I understand the answers, I can add them, assuming thats desirable.
Shortly after you've got ntpd running, you'll want to diagnose
your setup to see if it looks sane .. optimal.
ntpq is your friend:
#> ntpq -pcrv
remote refid st t when poll reach delay offset
-harpo 18.104.22.168 3 u 151 1024 377 1.219 -0.124
+mail01.tjgroup. 22.214.171.124 2 u 156 1024 377 206.401 -13.005
*adsl.remco.org .PG0A. 1 u 172 1024 377 195.164 -5.140
+ntp.aramiska.ne 172.16.33.1 2 u 137 1024 377 186.166 -10.974
-ntp1.us.grundcl 126.96.36.199 2 u 5 1024 377 99.248 -16.884
LOCAL(0) LOCAL(0) 13 l 33 64 377 0.000 0.000
assID=0 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg,
version="ntpd 4.2.0a at 1:4.2.0a+stable-8-r Fri Oct 28 15:39:49 CEST 2005
processor="i586", system="Linux/2.6.17-rc3-mm1-tunehrt-sk", leap=00,
stratum=2, precision=-18, rootdelay=195.164, rootdispersion=41.201,
reftime=c8131944.fec918e3 Mon, May 15 2006 8:14:12.995, poll=10,
clock=0xc81319f0.c20913a4, state=4, offset=-6.457, frequency=-0.384,
noise=3.925, jitter=5.886, stability=31.015
08:21:08 up 20:25, 1 user, load average: 0.00, 0.00, 0.00
* I have 4 timeserver entries;
* they have somewhat hi delays - not ideal, but a function of the dns
lookup of *.pool.ntp.org
(Ive just switched to 0-2.us.ntp.org, but not for these measurements)
* time-source (table) jitter is nice and low
* poll period is 1024, nice and long, indicates ntpd is 'happy' with
? refid - Ive seen other listings with different stuff here,
PPS - pulse per second - usually off an atomic source, maybe GPS
they mostly look like IPs,
are they some kind of hierarchy id, ie hash on path of clock-refs /
? delay, offset, jitter are in milliseconds ? (if rtfm, I havent seen
it, pointers welcome)
good values are _______
WRT the state variables, (the -crv part of the above listing)
rootdispersion - lower is better
maximum error of the local clock relative to the reference clock.
rootdelay - recap of *entry in peers table
? units of each field ?
? noise - lower is better ? relationship to jitter, wander ?
? stability - higher is better ?
add post-note: for a fuller understanding (re-)read the rfc
? *frequency* ? I have special interest here ..
this var tells how much ntpd has pushed your timesource away from
its natural free-running frequency.
Ive written a 'clocksource' driver for linux-2.6.17.rc3-mm1 to use a 32
attached to a 27 mhz XO, and Ive been 'sanity' checking it with ntpd.
Ive found that ntp said my frequency=18.fuzz, so it looked like my clock
To test what I could, I included a 'ppm' mod-param to tell the driver
the actual frequency of the XO. (in integer hz correction to default
Before setting ppm = -18, ntpq -pcrv reported a freq of -19.fuzz, and
now its -0.384.
Allowing for temp diffs over the duration of the tests ( 20 hrs)
that seems to match nicely with expectations, but Id appreciate hearing
you all agree with my interpretation of things (I could be biased;)
thanks in advance
More information about the questions