[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
doubt.
>
> 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