[ntp:questions] Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

David Woolley david at ex.djwhome.demon.co.uk.invalid
Fri Aug 29 21:08:58 UTC 2008

Steve Kostecke wrote:
> On 2008-08-28, David Woolley <david at djwhome.demon.co.uk> wrote:
>> Steve Kostecke wrote:
>>> ntpq -c"rv 0 offset" will tell you the current offset of your ntpd.
>> Careful. That is "Offset", not the common sense meaning of offset,
>> which might be put something like: the true error between the local
>> clock and true time.
> Let's see ... there's the offsets shown with:

I don't understand what you are demonstrating.  Without a measurment of 
local clock error to a resolution of about 10 microseconds, in this 
case, you cannot compare these offsets against the actual error, 
although you can guess that the actual error might be of the order of 50 
microseconds, relative to the systematic error in your time sources, 
although one really cannot make good statistical inferences from 
essentially one measurement; I've also given Dr Mills the benefit of the 

> ntpq -c"rv 0 offset"
> ntpq -p
> ntpdc -c kern | grep offset
> Take your pick ...
> Running all of those commands together against one of my systems
> produces the following (I've combined the two ntpq invocations):
> $ ntpq -pc"rv 0 offset" edge_box  | awk '/offset=/ { print }; \
> /^*/ { print $1 " " $9}'; ntpdc -c kern edge_box | grep offset
> offset=0.421
> *ntp.cox.net 0.264
> pll offset:           0.000407 s

pll offset and rv offset are pretty much the same, which is what you 
would expect, as they are both averages from the same set of time 
sources.  cox.net is different, although of the same order of magnitude. 
but represents the value for a single source.

More information about the questions mailing list