Reset kernel time (PLL/FLL)

Question

ntp trys to adjust the kernel's time variables, in order to improve the performance of a free-running time.

I am searching a way to reset these variables, but I can't find a programm/command to do so.

Thanks everyone for helping me!

Answer 1

I think you must be talking about the NTP Drift file. From Dr Mill's (originator of NTP) website:

During operation ntpd measures and corrects for incidental clock frequency error and occasionally writes the current value to a file specified by the driftfile /etc/ntp.drift configuration command. If ntpd is stopped and restarted, it initializes the frequency from this file and avoids the potentially lengthy interval to relearn the correction.

Deleting the drift file and restarting the ntp daemon so solve your problem. In debian, you'd do the following (note that the drift file may be stored in different places...you can always use the "locate" command to find it):

invoke-rc.d ntp stop
rm /var/lib/ntp/ntp.drift
invoke-rc.d ntp start

Answer 2

ntptime:

DESCRIPTION

This program is useful only with special kernels described in the A Kernel Model for
Precision Timekeeping  page. It reads and displays time-related kernel variables using
the ntp_gettime() system call. A similar display can be obtained using the ntpdc
program and kerninfo command.

You can set:

• frequency offset
• estimated error
• clock offset
• time constant

I am assuming those are the kernel time variables you are talking about. Please let me know if there are others you are interested in

Answer 3

These variables are calculated to compensate the local kernel clock based on the ntp server clock. The local kernel clock is calibrated during startup of the kernel only. Check the kernel log, for instance

Fast TSC calibration using PIT
Detected 2093.938 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency.. 4187.87 BogoMIPS (lpj=2093938)

When the local clock deviates too much of the ntp server clock, the PLL tracking will be clipped to the maximum of 500ppm, as in this example

# ntpdc -c kerninfo
pll offset:           -3.9831e-05 s
pll frequency:        -500.000 ppm
maximum error:        0.033146 s
estimated error:      2.2e-05 s
status:               2001  pll nano
pll time constant:    4
precision:            1e-09 s
frequency tolerance:  500 ppm

Resetting the pll frequency does not help on the long term, because it's the kernel timer itself that was estimated insufficiently accurate during boot. So the PLL frequency will drift again to its maximum. So in my opinion, only a reboot may help.