Re: gettimeofday() jumping into the future

["john stultz" <johnstul@us.ibm.com>]

On Thu, Apr 3, 2008 at 5:44 AM, James Courtier-Dutton
<James@superbug.co.uk> wrote:
>  It should be:
>  treat cycle_now and cycle_last as unsigned.
>  unsigned tmp;
>  tmp = cycle_now - cycle_last;
>  if (tmp > max_difference_threshold) cycle_now = cycle_last;
>
>  This correctly handles cycle_now going backwards as well as wrap around.
>
>  The only way to catch all edge cases is to be able to make an assumption
>  on the maximum acceptable difference between cycle_now and cycle_last,
>  where difference is the shortest distance between values if they were
>  pointers into a ring buffer. The other assumption made here is that the
> wrap around only happens at max_uint of cycle_now.

Yea. I see Thomas' patch was applied then reverted as it caused
problems with the TSC reseting over suspend and resume (since the
timekeeping core doesn't have a hook into the tsc clocksource to
inform it that the comparision is invalid, so the resume-time read
will always return the cycle_last value and not the actual smaller TSC
value).

This suggested bounding of how much a negative value is considered
valid would resolve this issue, since really the scope of this fix is
very small negative offsets due to the TSC being ever so slightly out
of sync between processors (but not enough to warrent throwing the TSC
out as a valid clock source).

-john