Discussion:
Trim clock rate
AGC
2013-11-22 21:04:47 UTC
Permalink
Is there a way to trim the clock rate in the kernel? Watching ntpd run
it seems to settle on a clock PPM offset of about -75. I was thinking
of testing a hypothesis but the first step is determining if that offset
can be trimmed away so that ntpd's corrections hover around zero.
Greg Troxel
2013-11-26 00:28:21 UTC
Permalink
Post by AGC
Is there a way to trim the clock rate in the kernel? Watching ntpd run
it seems to settle on a clock PPM offset of about -75. I was thinking
of testing a hypothesis but the first step is determining if that offset
can be trimmed away so that ntpd's corrections hover around zero.
If you are running ntpd and it uses the kernel pll, there is basically
little point, because it's basically doing this already every increment.

man 2 ntp_adjtime
http://tools.ietf.org/html/rfc1589

However, you could make the kernel code make the used rate adjustment be
-75 ppm plus what's commanded, and back out the -75 on read. That is
only a few lines of kernel code, probably.

I'm happy to answer further questions (after you've read the man page,
RFC, and corresponding kernel code :-).
AGC
2013-11-26 01:17:47 UTC
Permalink
Post by Greg Troxel
Post by AGC
Is there a way to trim the clock rate in the kernel? Watching ntpd run
it seems to settle on a clock PPM offset of about -75. I was thinking
of testing a hypothesis but the first step is determining if that offset
can be trimmed away so that ntpd's corrections hover around zero.
If you are running ntpd and it uses the kernel pll, there is basically
little point, because it's basically doing this already every increment.
man 2 ntp_adjtime
http://tools.ietf.org/html/rfc1589
However, you could make the kernel code make the used rate adjustment be
-75 ppm plus what's commanded, and back out the -75 on read. That is
only a few lines of kernel code, probably.
I'm happy to answer further questions (after you've read the man page,
RFC, and corresponding kernel code :-).
Heh, I'll look over the RFC, thanks. :) What I don't want to do is just
fudge the number that ntpd sees, I want to actually trim the clock so
that the true correction hovers around zero instead of -75 PPM.

I understand that ntpd is changing it, that's what it's supposed to do.
However, I have a theory about one of the various instabilities on this
particular system (posted to the list before). To test the hypothesis I
need to move the kernels tick rate such that ntpd, on average, keeps its
adjustments close to zero (or, conversely, that the adjustments seen by
the kernel sum to an average of zero).

Continue reading on narkive:
Loading...