On Thu, Nov 4, 2010 at 22:22 UTC, David L. Mills <[email protected]> wrote:
> Miroslav,
>
> IT IS NOT S BUG. Specifically, the Unix adjtime() semantics allows any
> argument, even if bizarre. The slew rate is constant at 500 PPM; the
> duration of the slew is calculate to amortize the argument as given. There
> is no way to "exceed" the slew rate; it is constant. You and Linux may have
> a different view, but the NTP implementation conforms to the traditional
> Unix semantics.
>
> Dave

Dr. Mills, I think you will find Miroslav in agreement with your view
about how adjtime() works.  As I understand it, the issue he's raising
is that during the initial offset convergence period only, ntpd does
not limit its slew rate to 500 PPM, as it does otherwise.  When it
exceeds 500 PPM, ntpd is assuming the full "adjustment + drift_comp"
value has been applied, when only the first 500 PPM has been.  As a
result, ntpd stops slewing the clock sooner than it should.

If that analysis is correct, two possible solutions come to mind.
Either ntpd can limit its slew rate during initial convergence to 500
PPM, or it can go faster on systems which allow it by using the
residual returned by adjtime() to accurately account for how much the
clock is being slewed.

Incidentally, Miroslav wrote a simple test program to measure the
maximum slew rate of adjtime(), by requesting a constant 100000 PPM
correction every second, and displaying the difference between the
requested amount and the residual returned:


#include <stdio.h>
#include <sys/time.h>
#include <unistd.h>

int main() {
        struct timeval tv, otv;

        tv.tv_sec = 0;
        tv.tv_usec = 100000;

        while (1) {
                if (adjtime(&tv, &otv)) {
                        printf("fail\n");
                        return 1;
                }
                printf("%ld\n", tv.tv_usec - otv.tv_usec);
                sleep(1);
        }

        return 0;
}

On Linux and FreeBSD 6.4, this displays a rock-steady "500" every
second after the first.  On OpenSolaris, it's around 63000.
Presumably the Solaris 10 you're using is similar.  If so, you should
be able to reproduce Miroslav's problem on FreeBSD, but not Solaris,
which will happily apply up to 63 msec/sec of slew.  By starting with
an initial offset just under the step threshold, ntpd should exceed
FreeBSD adjtime()'s ability to keep up during the initial offset
convergence.

Cheers,
Dave Hart
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions

Reply via email to