Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I am using the LAPIC timer as my system timer. For timers like the HPET, we know the oscillator that drives them and the amount of drift it has (e.g. HPET it's driven by a 10 MHz of ~ 14.318MHz clock with a +- 0.05% drift). However, from where can I get relative info for the LAPIC timer?
In the Intel manuals is stated that:
The time base for the (APIC) timer is derived from the processor’s bus clock, divided by the value specified in the divide configuration register.
So, now the question becomes: by which oscillator the processor’s bus clock is generated? Is it generated by the standard system clock crystal oscillator using a PLL? Which is the frequnecy drift of this oscillator?
The time base for the (APIC) timer is derived from the processor’s bus clock, divided by the value specified in the divide configuration register.
That's probably old/obsolete information (from back when CPU/s, memory and PCI host controllers all shared a single/common bus; before things like hyper-transport and quickpath started being used).
limp wrote:So, now the question becomes: by which oscillator the processor’s bus clock is generated? Is it generated by the standard system clock crystal oscillator using a PLL? Which is the frequnecy drift of this oscillator?
There is no generic answer, other than "there is no generic answer, other than...". Where the local APIC timer's clock comes from (and what sort of drift there is, and if at actually has anything to do with any bus) depends on which specific CPU, chipset and motherboard.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
The time base for the (APIC) timer is derived from the processor’s bus clock, divided by the value specified in the divide configuration register.
That's probably old/obsolete information (from back when CPU/s, memory and PCI host controllers all shared a single/common bus; before things like hyper-transport and quickpath started being used).
Is it really obsolete? Because it is the only information given in the Intel manuals (even until now) regarding the APIC timer's time base and it hasn't been removed.
Brendan wrote:
limp wrote:So, now the question becomes: by which oscillator the processor’s bus clock is generated? Is it generated by the standard system clock crystal oscillator using a PLL? Which is the frequnecy drift of this oscillator?
There is no generic answer, other than "there is no generic answer, other than...". Where the local APIC timer's clock comes from (and what sort of drift there is, and if at actually has anything to do with any bus) depends on which specific CPU, chipset and motherboard.
Oh, in that case it's probably the clock near the top left of Figure 2 (on page 13).
If local APIC timer drift actually matters, then synchronise with the RTC and/or NTP. For example, every 2 seconds determine if the CPU's local APIC timer is running slower/faster than the RTC and adjust your "local APIC timer ticks per second" so that it (gradually, not all at once) compensates for any difference (and then maybe synchronise the RTC with NTP).
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Thanks for the reply. So, as it looks like, this is what the Northbridge calls "differential host clock" as it seems to drive the NB as well. What I guess is that it is the IDT (CV110NPVG) clock generator (see here http://www.lckdanny.com/wordpress/?m=200905) which basically PLLs the board's crystal frequency. So, if we assume that the crystal oscillator that drives the clock generator runs at 14.318182 MHz, then 133.333 / 14.318182 ~ 9.3121 => 9 or 10 should be the PLL multiplier used by the clock generator. Does that make any sense?
limp wrote:Thanks for the reply. So, as it looks like, this is what the Northbridge calls "differential host clock" as it seems to drive the NB as well. What I guess is that it is the IDT (CV110NPVG) clock generator (see here http://www.lckdanny.com/wordpress/?m=200905) which basically PLLs the board's crystal frequency. So, if we assume that the crystal oscillator that drives the clock generator runs at 14.318182 MHz, then 133.333 / 14.318182 ~ 9.3121 => 9 or 10 should be the PLL multiplier used by the clock generator. Does that make any sense?
Are you writing an OS specifically for the D945GCLF2 motherboard and nothing else, or obsessing over irrelevant details for no reason whatsoever, or both?
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Brendan wrote:
Are you writing an OS specifically for the D945GCLF2 motherboard and nothing else, or obsessing over irrelevant details for no reason whatsoever, or both?
LoL! Well, firstly I am trying to write a fine-tuned OS for the D945GCLF2 and secondly to identify some of the possible sources of varying interrupt latency on the platform (mainly interested in the case of a LAPIC timer interrupt).
limp wrote:LoL! Well, firstly I am trying to write a fine-tuned OS for the D945GCLF2 and secondly to identify some of the possible sources of varying interrupt latency on the platform (mainly interested in the case of a LAPIC timer interrupt).
Writing an OS for one specific motherboard is a mistake. For example, the D945GCLF2 was launched in 2008 (and is listed by Intel as "end of interactive support") - it's mostly obsolete now and in 5 to 10 years time (when you're "finished" writing your OS) it'll be ancient. If you really do want to write an OS for one specific motherboard, then you should target something that won't exist until 2016 at the earliest. A much more sane approach is to write an OS that doesn't make unnecessary assumptions (and then quickly make any minor modifications to "tune it" for a specific motherboard, based on profiling/measurements, after everything is done, if necessary).
Also note that the largest causes of interrupt latency will be software (e.g. disabling interrupts during task switches, PCI IRQ sharing, the PIC/APIC's IRQ priority scheme, etc) and firmware (e.g. SMM). Any jitter in the local APIC timer's clock source will be about as important as ants on a rocky 4WD track.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Brendan wrote:
Also note that the largest causes of interrupt latency will be software (e.g. disabling interrupts during task switches, PCI IRQ sharing, the PIC/APIC's IRQ priority scheme, etc) and firmware (e.g. SMM). Any jitter in the local APIC timer's clock source will be about as important as ants on a rocky 4WD track.
I guess you're right. The jitter in the local APIC timer's clock source should be tiny anyway. Do you happen to know any other sources of timer interrupt jitter related to the firmware?
