On Wed, 10 Dec 2014, Santosh Shukla wrote:
The causes I could find:
Clockevent device's counter overflow: When we need to program a clockevt device for times larger than it can handle, we program it for max time and then reprogram again on expiration. Because of hardware counter limitations we have to do it this way and this isn't really a spurious interrupt as we programmed it that way.
Hardware timer firing before its expiration: Yes, its hard to digest but from my tests it looks like this does happen. Will circulate another mail once I am sure about it.
Nothing we can do about.
- Difference between time returned by hrtimer_update_base() and clockevt device's notion of time: Wanted to discuss this here..
The clock event device and the clock source can run at different frequencies. So the conversion from nsec to event ticks can cause slight errors which are only observable when the delta gets larger.
The clock event device conversion from nsecs to timer ticks is calculated at setup time once. It's known to be not completely precise.
The clock source conversion which we use for reading time can be changed by recalibration (we do that for TSC) and by NTP adjustments.
So even if we would calibrate the clock event device better, then we still would need to take the NTP adjustments into account. And given the zoo of timers we have, certainly not a trivial exercise.
Need to think about a bit more.
Thanks,
tglx