Scott Reynolds (scottr@esdi.org) writes:

>I'm not sure if you can decide on these or not, but here's a heads-up:  
>PR's 94 and 1887 both recommend that tickadj be changed for NTP, but the 
>former raises the question of whether or not they are necessary if the 
>PLL code is committed.

hi,

I'm not sure how to reach those responsible for kernel PRs and it's
not entirely clear I should be fixing this, but:

As I understand NTP, the basic problem here is rate control.  An NTP
daemon is continually disciplining the kernel's clock.  If the kernel
does not include NTP precision timekeeping support, then xntpd has no
choice but to use adjtime().  Adjtime  tweaks the clocktickadj.  The
rate-control problem is that if tickadj is large, xntpd may try and
step the clock by a larger amount than will complete within a single
NTP polling interval (i.e., before xntpd tries to adjust the clock
rate once more.)


If kernel NTP support is available and enabled in /etc/ntp.conf, then
the magnitude of tickadj is simply not an issue for xntpd.  The xntpd
distribution also includes a utility that changes the value of tickadj
in a running kernel.  However, it can't open /dev/kmem write-only :-(.

In any case, before I integrated kernel PLL support, I added the
following fragment to pmax kernels in arch/pmax/pmax/clock.c: 

        /*
         * Reset tickadj to ntp's idea of what it should be
         * XXX this should be in conf/param.c
         */
        tmp = (long) tick * 500L;
        tickadj = (int)(tmp / 1000000L);
        if (tmp % 1000000L > 0)
                tickadj++;


If it's worth supporting xntpd on kernels that do NOT have "options
NTP", then I guess  this  could go into conf/param.c.  I would
appreciate feedback as to whether that's a useful thing to do.
(I think in general, those who wish to run NTP should and will
add "options NTP" to their kernels.)  In summary, I think these PRs
are now mooot and should be closed.

However, I see no reason to not make tickadj readable and alterable
via sysctl.  The only question is if it's worthwhile.

I'd welcome opinions either way, as long as they come with some
supporting rationale.

thanks
--Jonathan