garskof wrote:
I had the same clock drift when it was set up with WinDoze, so I doubt
it is SUSE that is at fault.
WinDoze exhibits the same problem with lost clock interrupts. The
difference is that there is nothing you can do about WinDoze except run
a better O/S! The problem results from interrupts being masked or
disabled for two or more consecutive clock "ticks". Only the first
"tick" registers, the rest are lost. This typically happens during
heavy disk activity. Runing the multi-media timers can also gum things
up royally but there is a fix or workaround for that. If your clock
gains rather than loses time, you needn't worry about lost interrupts.
If the machine drifts badly when idle, the problem is probably not lost
interrupts.
So ntp will only correct if the drift is less then some value? On
startup it corrects no matter how off the clock is, but after that it
never corrects again. I assumed there was a way to increase the number
of times per day ntp checks with its servers. I guess a cron of ntpdate
evey hour or so is my own choice. Sigh.
If you start NTPD with the -g option it will set the clock on a one time
basis. If the clock is drifting at a rate greater than or equal to 500
PPM, there is nothing NTPD can do about it; the limitation is built
into the O/S kernel I believe.
While computer clocks generally do not win any prizes for accuracy, very
few are off by more than 500 PPM. A small sampling in my household
shows three Sun Ultra 10 workstations with frequency errors of less than
10 PPM and a DEC Alphastation 200/233 with an error of less than 30
PPM. I think that with a sample large enough to be statistically
significant, the majority would fall within +/- 100 PPM. Your machine
is way the hell and gone beyond 3 sigmas!
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
