[ntp:questions] how do I lock in average frequency correction

Chuck Swiger cswiger at mac.com
Tue Feb 14 16:48:51 UTC 2012

On Feb 13, 2012, at 10:20 PM, Ron Frazier (NTP) wrote:
> Perhaps a silly question, but, does the "tick" that drives the OS software clock originate from the RTC or from the CPU master clock at 2 GHz or whatever?  Just trying to understand how this stuff works.

On classic IBM AT hardware, an Intel 8253 PIT (Programmable Interval Timer) using a 1.19MHz crystal is used to generate a periodic clock interrupt via the Intel 8259 PIC (Programmable Interrupt Controller) on IRQ 0, which is commonly referred to as "system timer" in IRQ docs.  Typically, the OS would arrange for 60, 64, or 100 of these interrupts per second.  The BIOS RTC clock is connected to IRQ 8; it's not commonly used as the primary system timer interrupt because it was expected to run at exactly 18.2 Hz for the RTC to keep time properly for (eg) DOS-based software, and it is on the secondary or slave 8259 connected via cascade to the primary 8259's IRQ 1.

More modern hardware has replaced the pair of 8259 PICs with an APIC, originally the Intel 82093AA; and the 8253 PIT has been replaced by HPET, although modern x86 hardware will also have alternatives like the ACPI clock and TSC.

In terms of software, earlier operating systems ran the kernel scheduler's quantum at the system timer interrupt rate; later systems tended to decouple them, and might also add yet more timers for profiling or gathering process usage stats.  A typical example might be the system timer calling hardclock() at 60 or 100 Hz, the scheduler running at 1000Hz which calls softclock(), and adds a fixed estimate of time to the kernel's idea of "now" for each scheduler tick based upon the ratio between the interrupt waits, and/or possibly looking at the TSC. [1]

The profiling and stats timers tended to run at odd rates like 1013 HZ and 91Hz, which are deliberately chosen to not correspond with the scheduler tick and thus provide more fair coverage (and to try to detect processes which game the process accounting system by doing work for just less than a scheduler tick, and then blocking so that they aren't active when the scheduler runs).  Systems prefer to use the HPET for these, but it is possible to hook onto the RTC interrupt handler on IRQ8 at (eg) 91Hz, and only pass 1 interrupt of 5 onto the RTC's ISR-- giving that the expected 18.2Hz frequency.  I seem to recall that video card BIOSes of a certain era (VESA BIOS linear framebuffer stuff) also hooked into IRQ8....




[1]: This code has been historically buggy to very buggy in various platforms, and can exhibit many unfortunate behaviors such as having the clock appear to be "stuck" for one or more scheduler ticks, or even have time going "backwards", etc.

More information about the questions mailing list