]> Pileus Git - ~andy/linux/commit
time: Avoid accumulating time drift in suspend/resume
authorJohn Stultz <john.stultz@linaro.org>
Wed, 1 Jun 2011 05:53:23 +0000 (22:53 -0700)
committerJohn Stultz <john.stultz@linaro.org>
Tue, 21 Jun 2011 23:55:37 +0000 (16:55 -0700)
commitcb33217b1b2523895eb328a0b13fb3b1c4000969
treef3ce72c0f6cb9a23411c2639acf300f1f453a3c0
parentcb5de2f8d0306be38f9b377b8a5c56acca7dbc3d
time: Avoid accumulating time drift in suspend/resume

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: John Stultz <john.stultz@linaro.org>
kernel/time/timekeeping.c