• John Stultz's avatar
    time: Avoid accumulating time drift in suspend/resume · cb33217b
    John Stultz authored
    Because the read_persistent_clock interface is usually backed by
    only a second granular interface, each time we read from the persistent
    clock for suspend/resume, we introduce a half second (on average) of error.
    
    In order to avoid this error accumulating as the system is suspended
    over and over, this patch measures the time delta between the persistent
    clock and the system CLOCK_REALTIME.
    
    If the delta is less then 2 seconds from the last suspend, we compensate
    by using the previous time delta (keeping it close). If it is larger
    then 2 seconds, we assume the clock was set or has been changed, so we
    do no correction and update the delta.
    
    Note: If NTP is running, ths could seem to "fight" with the NTP corrected
    time, where as if the system time was off by 1 second, and NTP slewed the
    value in, a suspend/resume cycle could undo this correction, by trying to
    restore the previous offset from the persistent clock.  However, without
    this patch, since each read could cause almost a full second worth of
    error, its possible to get almost 2 seconds of error just from the
    suspend/resume cycle alone, so this about equal to any offset added by
    the compensation.
    
    Further on systems that suspend/resume frequently, this should keep time
    closer then NTP could compensate for if the errors were allowed to
    accumulate.
    
    Credits to Arve Hjønnevåg for suggesting this solution.
    
    CC: Arve Hjønnevåg <arve@android.com>
    CC: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
    cb33217b
timekeeping.c 29.5 KB