* 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. > > > >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? 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? Tony - 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/
