* George Anzinger <george@mvista.com> [050120 15:10]:
Tony Lindgren wrote:
* George Anzinger <george@mvista.com> [050119 16:25]:
Tony Lindgren wrote:
* George Anzinger <george@mvista.com> [050119 15:00]:
I don't think you will ever get good time if you EVER reprogramm the PIT. That is why the VST patch on sourceforge does NOT touch the PIT, it only turns off the interrupt by interrupting the interrupt path (not changing the PIT). This allows the PIT to be the "gold standard" in time that it is designed to be. The wake up interrupt, then needs to come from an independent timer. My patch requires a local APIC for this. Patch is available at http://sourceforge.net/projects/high-res-timers/
Well on my test systems I have pretty good accurate time. But I agree, PIT is not the best option for interrupt. It should be possible to use other interrupt sources as well.
But then again reprogramming PIT in my patch should not be that bad, as it's not done under load.
It should not matter where the timer interrupt comes from, as long as it comes when programmed. Updating time should be separate from timer
interrupts. Currently we have a problem where time is tied to the
timer interrupt.
In the HRT code time is most correctly stated as wall_time + get_arch_cycles_since(wall_jiffies) (plus conversion or two:)). This is some what removed from the tick interrupt, but is resynced to that interrupt more or less each interrupt.
That sounds very accurate :)
A second issue is trying to get the jiffies update as close to the run of the timer list as possible. Without this we have no hope of high res timers.
OK. But if the timer interrupt is separated from updating the time, the next timer interrupt should be programmable to happen exactly when a HRT timer needs it, right?
First, HRT uses a two phase system of timing. The first phase is the normal timer list expires the timer. The timer is then handed to the high res code which keeps a list of timers that are to expire prior to the next jiffie. An interrupt is scheduled to make this happen. Depending on the hardware available, this can come from the same timer or a different timer. For example on x86 systems with a local apic we use the apic timer to generate this interrupt. It triggers either a tasklet for UP or SMP with out per cpu timers or a soft irq for SMP systems with per cpu timers.
What this means is that, for timers near but just after a jiffie, the run_timer list being late can make the HR timer late.
Thanks for explaining that. So basically catching up with jiffies after skipping ticks could easily delay the HRT timer.
Any due in the "skipped time" would be late, as would any normal timers due during that time.
If jiffies was calculated from hw timer, updating time after skipping jiffies would be fast, and then this problem would go away, right?
No, you are still pulling the timers out of the timer list long after they should have expired.
This code on on sourceforge if you want a closer look...
I'll take a look at it.
Hmm, how about using a pool of programmable timers available on the system for the timer interrupts and HRT? Or is one interrupt source
always enough?
Hardware heaven :), but no thanks. A reliable tick generator for the jiffies timer and one additional timer (or one per cpu) works well in the x86.
If you have something like the PPC where you can mess with the timer with out loosing time, that works well also. The correct formulation would be a "clock" that can be read quickly and a timer tied to the same "rock" that uses the same count units as the clock. PARISC has a counter that just counts and a compare register. When they are equal an interrupt is generated. That is a nice set up.
Yes, many ARMs have this setup as well.
Now the X86 is bad and has little hope of being fixed for these reasons:
a.) the TSC is fast and easy to read but its not clocked at any given frequency and, on some platforms, it changes without notifying the software.
b.) the PIT and the PMTIMER are both in I/O space and so take forever to access.
c.) All three of these use different units (but at least the PMTIMER is (supposed to be) related to the PIT clock.
d.) the HPET, again is in I/O space. I suspect that it uses a reasonable "rock" but, as I understand it, it knocks out the PIT and, of course it uses units unrelated to all the others.
The timers on x86 are quite messy...
AMEN!
Tony
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
