William Kenworthy wrote:
Notice the difference in ntptrace between mine below and yours? The
asterisk in your ntpq table indicates that is the chosen server - but
not that it is actually locked to it - ntptrace is showing it is not
locked.
rattus ~ # ntptrace
localhost: stratum 6, offset 0.001309, synch distance 0.160683
moriah: stratum 5, offset -0.004895, synch distance 0.155622
dns.iinet.net.au: stratum 4, offset 0.001463, synch distance 0.135967
***Association ID 60244 unknown to server
rattus ~ #
Did you try the tinker panic 0 or -g arguments I suggested earlier? A
third option is to increase the slew window rather than stepping - the
default slew is less than what you are trying to force it to do so it
fails and gives up.
rattus ~ # ntptrace
localhost: stratum 6, offset 0.001309, synch distance 0.160683
moriah: stratum 5, offset -0.004895, synch distance 0.155622
dns.iinet.net.au: stratum 4, offset 0.001463, synch distance 0.135967
***Association ID 60244 unknown to server
rattus ~ #
I would suggest stopping ntpd and modifying the ntp.conf file as
suggested, deleting /etc/adjtime and the drift file then rebooting. Run
for a few hours and see if it still jumps time. ntpd will correct some
extreem time issues but it needs to be properly configured.
If it is actually jumping time rather than incorrect
drift/slew/adjustime issues then you need to track down why - good luck
with that! So far all I am seeing is a clock thats off too far to
correct and isnt being allowed to correct by the config
BillK
I added the -g option but have no idea why that will change anything.
According to the man page, it is for when the clock is more than 1000s
off which makes it outside the range ntp will change. Mine is off only
a few seconds and most of the time less than one second. So I fail to
understand why this option is going to do any good here. Maybe you can
explain it more?
It ran all night and most of this morning. It's still resetting like it
has in the past but not like on my old rig. Before I went to sleep I
reset the drift-file to about half what it set it to. It set it back to
500 so it is changing.
So, ntp can set the clock, it can change the drift file value but it
can't adjust the clock cycles to speed it up or slow it down. I think
I'm missing something in the kernel or something. I may compare my
kernel config files later on when I get some time. Try to rule that out.
Dale
:-) :-)
