Michael, do you know *any* generally-available Unix system with an internal cesium clock? Or even any currently-available HP-UX hardware with a calibrated, temperature-stabilized ("ovenized") quartz crystal oscillator in the Real-Time Clock?
I've understood that most built-in real time clocks in generally-available computers are based on regular non-ovenized crystal oscillators, which are somewhat sensitive to temperature - so the drift rate of the real time clock may depend on, among other things, the load level of the system (different load -> different in-chassis temperature -> slightly different RTC frequency).
Raj's statement would have technically needed a qualification ("Clock hardware in normal servers are not very accurate...") but because this group deals with HP-UX system administration and are clearly talking about a basic case of Unix xntpd, the omission would be within the limits of reasonable.
> As for the drift file, LATENTCY INCREASES OVER NETWORKS. The offset between the correct and incorrect times are know as 'drift'. And its just there to store the last offset, or drift, from the last syncing.
NTP does not simply sync to the timesource with the least latency. It collects time and latency information over time and builds error estimates for each timesource, *including* the local system clock.
According to the documentation of NTP, the drift file is *not* related to the network latency in any way. It is simply the frequency error (or the time error rate, which amounts to the same thing) of the local system clock, as determined using the best available idea of the correct time.
Xntpd client-side works by measuring the latency to configured network timesources (using the possibly-inaccurate local clock) and compensates for it, if the latency is deterministic. When the time information gained from network timesources is good enough, it is used to measure the accuracy of the local clock.
Because xntpd typically has no access to any absolutely correct time, this becomes an iterative process: a better estimate of local system clock error leads to more accurate measurements of network latency, which will in turn improve the quality of time information received from the network. With that, the error of the local clock can be measured more accurately, closing the cycle.
The drift file is used to store the known frequency error of the local system clock, so that this iterative process (which can take days) can be shortened after the xntpd is restarted.
MK
MK
