[ntp:bugs] [Bug 807] New: ntpq -p offset not updated at every poll

[David L. Mills]

Alain,

The values that ntpq reports are precisely the state variables upon 
arrival of the ntpq request packet. However, by design the state 
variables might not be updated at every poll response. The clock filter 
algorithm might choose to ignore one or more server packets for the 
reasons called out in the specification. So, what you report is not a 
bug; it is a feature.

Dave

Alain Guibert via the NTP Bugzilla wrote:

> http://bugs.ntp.isc.org/807
>
> Summary: ntpq -p offset not updated at every poll
> Product: ntp
> Version: 4.2.5
> Platform: PC
> OS/Version: Linux
> Status: NEW
> Severity: normal
> Priority: P3
> Component: ntpd
> AssignedTo: stenn at ntp.org
> ReportedBy: alguibert+bni at free.fr
> CC: bugs at ntp.isc.org
>
>
> Hello,
>
> When ntpd runs as client of one server, the offset (and delay) reported
> by "ntpq -p" is not always the value of the last poll. It's sometimes an
> older value. It seems that the computed frequency correction is then
> also not updated. They are all updated together later, perhaps after
> 2, 4 or 8 polls.
>
> Example: The machine runs ntpd 4.2.5p20 with a minimal ntp.conf of one
> line "server 192.168.1.1". After some time:
>
> | $ ntpq -pn
> | remote refid st t when poll reach delay offset jitter
> | 
> ==============================================================================
> | *192.168.1.1 LOCAL(0) 9 u 6 64 377 0.469 -1.180 0.591
> |
> | $ ntpq -crv
> | assID=0 status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg,
> | version="ntpd 4.2.5p20-o Mon Apr 2 17:32:22 UTC 2007 (3)",
> | processor="i586", system="Linux/2.0.40", leap=00, stratum=10,
> | precision=-17, rootdelay=0.469, rootdispersion=23.324, peer=50442,
> | refid=192.168.1.1,
> | reftime=c9bbeef3.25f0048f Mon, Apr 2 2007 23:06:59.148, poll=6,
> | clock=c9bbf07a.1f4e7140 Mon, Apr 2 2007 23:13:30.122, state=4,
> | offset=-1.180, frequency=-2.557, jitter=3.197, noise=1.111,
> | stability=0.756, tai=0
> |
> | $ ntpq -c "rv 50442"
> | assID=50442 status=9614 reach, conf, sel_sys.peer, 1 event, event_reach,
> | srcadr=origan, srcport=123, dstadr=192.168.1.7, dstport=123, leap=00,
> | stratum=9, precision=-18, rootdelay=0.000, rootdispersion=11.551,
> | refid=LOCAL(0), reach=377, unreach=0, hmode=3, pmode=4, hpoll=6,
> | ppoll=6, flash=00 ok, keyid=0, ttl=0, offset=-1.180, delay=0.469,
> | dispersion=5.154, jitter=0.591,
> | reftime=c9bbf04b.169f90a5 Mon, Apr 2 2007 23:12:43.088,
> | org=c9bbf074.254a2f8b Mon, Apr 2 2007 23:13:24.145,
> | rec=c9bbf074.2573bee6 Mon, Apr 2 2007 23:13:24.146,
> | xmt=c9bbf074.25437fe4 Mon, Apr 2 2007 23:13:24.145,
> | filtdelay= 0.63 0.57 0.57 0.53 0.58 0.53 0.58 0.47,
> | filtoffset= -0.29 -0.35 -0.40 -0.49 -0.59 -0.74 -0.92 -1.18,
> | filtdisp= 0.01 0.97 1.93 2.91 3.88 4.86 5.80 6.75
>
> The currently reported offset -1.180 and delay 0.469 dates from 8 polls
> ago, as can be seen in the last column of the filter. The frequency
> -2.557 has not changed in the last 8 minutes, confirmed both by
> ntpq -crv and ntptime. The same happens with stable 4.2.4.
>
> Shouldn't all those values be updated at every poll?
>
> Alain.
>