[ntp:questions] Horrible performance with 4.2.8p3?

Harlan Stenn stenn at ntp.org
Mon Dec 7 10:17:56 UTC 2015


ntpdc returns values in seconds.

ntpq returns values in milliseconds.

H
--
Marco Marongiu writes:
> I've been doing a little research here.
> 
> On one server I have the munin plugins version 2.0.6 from Debian
> packages in backports.
> 
> The munin plugin ntp_kernel_pll_off uses the output of ntpq -c kerninfo
> or ntpdc -c kerninfo, whatever is available, then matches /^pll offset:/
> and prints the value:
> 
> ~# ntpdc -c kerninfo
> pll offset:           -0.00024676 s
> pll frequency:        -81.448 ppm
> maximum error:        0.797547 s
> estimated error:      0.000573 s
> status:               2001  pll nano
> pll time constant:    10
> precision:            1e-09 s
> frequency tolerance:  500 ppm
> ~# ntpdc -c kerninfo | awk '/^pll offset:/ { print $3 }'
> -0.00024652
> 
> Now, what happens with 4.2.8? I tried to do the same on my workstation
> running Debian Jessie and ntpd 4.2.8p3. ntpdc -c kerninfo fails:
> 
> bronto at brabham:~$ sudo ntpdc -c kerninfo
> localhost: timed out, nothing received
> ***Request timed out
> bronto at brabham:~$
> 
> ntpdc -c kerninfo works, but...
> 
> bronto at brabham:~$ sudo ntpq -c kerninfo
> associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer,
> pll offset:            -0.075818
> pll frequency:         7.23193
> maximum error:         0.2435
> estimated error:       0
> kernel status:         pll nano
> pll time constant:     7
> precision:             1e-06
> frequency tolerance:   500
> pps frequency:         0
> pps stability:         0
> pps jitter:            0
> calibration interval   0
> calibration cycles:    0
> jitter exceeded:       0
> stability exceeded:    0
> calibration errors:    0
> bronto at brabham:~$
> 
> No unit, but I'd speculate that pll offset is milliseconds instead of
> seconds... That's what confuses munin, I believe: where the two commands
> provide the same information, ntpq prints it without specifying the unit
> AND uses a different unit for pll offset.
> 
> I'm not sure if that should be considered a bug in ntpq. In case, let me
> know and I'll submit a bug report.
> 
> Ciao
> -- bronto
> 
> 
> PS: For your reference, here's the code of the munin plugin.
> 
> > ~# cat /etc/munin/plugins/ntp_kernel_pll_off 
> > #!/bin/sh
> > # -*- sh -*-
> > 
> > : <<EOF
> > 
> > =head1 NAME
> > 
> > ntp_kernel_pll_off - Plugin to monitor the kernel's PLL offset for the
> > NTP status
> > 
> > =head1 CONFIGURATION
> > 
> > No configuration
> > 
> > =head1 AUTHORS
> > 
> > Unknown author
> > 
> > =head1 LICENSE
> > 
> > GPLv2
> > 
> > =head1 MAGIC MARKERS
> > 
> >  #%# family=auto
> >  #%# capabilities=autoconf
> > 
> > =cut
> > 
> > EOF
> > 
> > export PATH=/usr/local/sbin:$PATH
> > 
> > if [ "$1" = "autoconf" ]; then
> >     { ntpq -c kerninfo; ntpdc -c kerninfo; } 2>/dev/null |
> >     awk 'BEGIN { ev=1; }
> >          /^pll offset:/ { ev=0; }
> >          END { if (ev == 0) { print "yes";} else { print "no"; } exit ev; }
> '
> >     exit 0
> > fi
> > 
> > if [ "$1" = "config" ]; then
> >     echo 'graph_title NTP kernel PLL offset (secs)'
> >     echo 'graph_vlabel PLL offset (secs)'
> >     echo 'graph_category time'
> >     echo 'graph_info The kernel offset for the phase-locked loop used by NT
> P'
> >     echo 'ntp_pll_off.label pll-offset'
> >     echo 'ntp_pll_off.info Phase-locked loop offset in seconds'
> >     exit 0
> > fi
> > 
> > printf 'ntp_pll_off.value '
> > 
> > if [ $(ntpq -c version | grep --extended-regexp --only-matching '[[:digit:]
> ]\.[[:digit:]]\.[[:digit:]]' | tr -d '.') -ge 427 ]
> > then
> >     cmd=ntpq
> > else
> >     cmd=ntpdc
> > fi
> > 
> > $cmd -c kerninfo | awk '/^pll offset:/ { print $3 }'
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 


More information about the questions mailing list