Re: gettimeofday resolution seriously degraded in test9

[Stephen Hemminger <shemminger@osdl.org>]

On Wed, 29 Oct 2003 11:07:45 +0100
Gabriel Paubert <paubert@iram.es> wrote:


> Consider the following:
> 
> - t-2: interrupt A arrives and starts being serviced
> - t-1: interrupt B arrives but delayed in the APIC
> - t: timer interrupt arrives (it is delayed too)
> - t+x1: return from interrupt A
> - t+x2: interrupt B serviced
> - gettimeofday for time stamping, the returned value will actually 
>   be frozen at t-1 for HZ=1000 or t-5 for HZ=100, while the actual
>   time is t+something with something maybe up to a few tens of
>   microseconds, instead of t+x2-1 or t+x2-5 which would be 
>   clearly better.
> - t+x3: timer interrupt, time steps suddenly now (or in
>   the following BH, can't remember) from t-1 to the correct
>   value, creating a fairly large discontinuity.
> 
> So what I'm asking you is to change the code so that the discontinuities
> are minimized. That's quite important for some applications; actually
> in my case the out-of-order gettimeofday don't matter as long as the
> steps are small because I don't sample fast enough to be affected
> by them, but getting the timestamp wrong by tens of microseconds is bad 
> for evaluating the derivatives of the value read from a position encoder, 
> as needed for servo loops for example.

The suggestion of using time interpolation (like ia64) would make the discontinuities
smaller, but still relying on fine grain gettimeofday for controlling servo loops
with NTP running seems risky. Perhaps what you want to use is the monotonic_clock
which gives better resolution (nanoseconds) and doesn't get hit by NTP. 

A bigger possible change would be for the timer->offset functions to return nanoseconds,
then the offset adjustment code could smooth it out. It would save a divide.