James Wilkinson wrote:
jdow wrote:
Also try booting with "noapic" and "nolapic" options. (I'd LOVE to know why the APIC screws up the ntp operations.)
I'm sure the kernel developers would, too.
But it's not that improbable, if you think about it.
The kernel measures the passage of time by counting timer ticks. A timer works by sending interrupts to the CPU (which are received by the kernel) every so often. And a Programmable Interrupt Controller (such as the Advanced PIC, or APIC) is responsible for marshalling those interrupts and sending them on.
James.
I was browsing some of the 2.6 kernel sources recently. It seems that there have been major changes in the timekeeping since the last time that I looked at the sources (not sure if that was 2.2 or 2.4). I am NOT a kernel hacker, therefore read the following with some reservation. It appears that: -- the kernel actually runs with a much higher HZ (more clock ticks per second, smaller tick value which is in microseconds) than indicated by tickadj -- the kernel "lies" to user space and says that HZ is 100 (tick is 10000) for backward compatibility -- the kernel does miss clock interrupts; however it "compensates" by using another counter to detect missing ticks; there are several to choose from, depending on the architecture of the machine and the processor installed. Later Pentiums have a "TSC", a cycle counter that runs at the cpu clock rate; it is not available on early pentiums; it is also affected by CPU power management which lowers the CPU frequency to save power when lightly loaded (on some systems). APIC apparently specifies another clock counter which is not affected by the CPU speed throtteling. (I suspect that if you have a very old system, you WILL see clock interrupt loss because you don't have one of the newer features to compensate) -- When returning time to a user program (presumably including ntpd) the system does account for lost ticks using the timers, so lost ticks shouldn't be a problem (if the timers are present) -- From a previous experience with Red Hat's attempt to set HZ to a high value (in the 7.x series) I know that the fixed point calculations in the time routines were sensitive to the setting of HZ. The ACTUAL tick value computed (in those kernels) was incorrect due to truncation when converting from HZ to the actual clock constants. This was compensated by ntpd essentially recognizing this as a "frequency error" which it tuned out over time. It also saved the frequency correction in the "drift" file and used that when restarting. HOWEVER, the correction was different for various values of HZ, because the computation roundoff error would be different for each HZ. This meant that the value in "drift" deduced by ntpd for one kernel HZ was wrong when starting another kernel. Then ntpd would start with the wrong frequency correction and adjust over time. Not sure how this affects the new 2.6 kernel because I haven't looked at the new caluculations.
