2011/9/2 Miguel Gonçalves <m...@miguelgoncalves.com>:
> $ ntpq -p 10.0.2.2; ntpdc -c kerninfo 10.0.2.2
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> +10.0.2.10 .GPS. 1 u 734 1024 377 0.182 -0.149
> 0.034
> *10.0.2.9 .GPS. 1 u 235 1024 377 0.163 -0.055
> 0.029
> pll offset: -8.5e-05 s
> pll frequency: 44.545 ppm
> maximum error: 0.151092 s
> estimated error: 3.8e-05 s
> status: 0001
> pll time constant: 6
> precision: 1e-06 s
> frequency tolerance: 512 ppm
>
> For the FreeBSD PBX server
>
> asterisk# ntpq -pn ; ntpdc -c kerninfo
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> +10.0.2.10 .GPS. 1 u 843 1024 377 0.202 0.033
> 0.005
> *10.0.2.9 .GPS. 1 u 991 1024 377 0.186 0.029
> 0.017
> pll offset: 2.4324e-05 s
> pll frequency: 151.490 ppm
> maximum error: 1.03863 s
> estimated error: 2.1e-05 s
> status: 2001 pll nano
> pll time constant: 10
> precision: 1e-09 s
> frequency tolerance: 496 ppm
>
> BTW, what is the difference between 2001 pll nano and 0001 in the status?
The 0001 should have been followed by " pll" -- that it wasn't
suggests the system which built the ntpdc you're using didn't have
STA_PLL defined. I'm guessing that's a linux system, as there was a
problem with STA_ and MOD_ defines in Linux headers not too long ago.
2001 and 0001 are both hexadecimal, though it's not obvious from
context. The 0x1 bit is typically STA_PLL, meaning the kernel "loop
discipline" is operating in phase-locked loop mode (PLL) as opposed to
frequency-locked loop (FLL). The 0x2000 bit here is STA_NANO, meaning
the kernel loop discipline is fed offsets to nanosecond precision, as
opposed to microsecond precision used by earlier kernel loops.
ntpdc -c kerninfo is one of the unfortunate examples of where using
ntpdc built on the queried system can give better results than ntpdc
built on a different system. The text decoded on the status: line
from the hexadecimal value depends on ntpdc having been built against
the same system as ntpd, because bitfields are decoded only when the
relevant preprocessor macro is defined (such as STA_PLL or STA_NANO):
#ifdef STA_NANO
if (status & STA_NANO) (void)fprintf(fp, " nano");
#endif
When ntpdc is built on a system which doesn't have a
nanosecond-precision kernel loop, STA_NANO is not defined, and that
bit will not be decoded correctly when querying a ntpd built with
STA_NANO defined. Recent 4.2.7 snapshots have a new "ntpq -c
kerninfo" which is not so limited -- the decoding of bit values to
keywords is handled by the remote ntpd, not ntpq. That works only if
both your ntpd and ntpq are recent 4.2.7, however.
Cheers,
Dave Hart
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
