Message-ID: <5af5d2a5-767c-d313-3be6-cb6f426f1980@sent.com>
Date:   Thu, 9 Dec 2021 10:55:53 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Content-Language: en-US
To:     John Stultz <john.stultz@linaro.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Stephen Boyd <sboyd@kernel.org>
From:   Joel Daniels <jdaniels@sent.com>
Cc:     Joel Daniels <jdaniels@sent.com>, linux-kernel@vger.kernel.org
Subject: Time keeping while suspended in the presence of persistent clock
 drift
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi,
I have an x86 laptop whose CMOS (RTC) clock gains an extra 3.75 seconds 
per day that it is suspended (S3) or off. It keeps time quite accurately 
while awake using the TSC clock source. I use the machine about 1 hour 
per day with the machine in the S3 sleep state for the remaining 23 
hours. The machine is not usually connected to a network and I do not 
run an NTP daemon (though I do not believe this is relevant). When cold 
booting, I correct for the CMOS clock drift using hwclock before making 
the filesystem writable. When resuming from suspend-to-ram (S3), 
however, I must either use hwclock again (causing the system time to 
jump backwards and potentially upsetting programs like make) or use a 
large slew rate (absolute value greater than 1000 PPM) to correct the 
system clock. As far as I can tell there is currently no way to inform 
the kernel of my CMOS clock drift. Is this correct? I am considering 
writing a patch to make the kernel compensate for the drift of the 
persistent and/or RTC clock(s) when injecting sleep time. The patch 
would require user space to inform the kernel of the drift (probably via 
sysfs). Does this seem like a good approach? Regards, Joel Daniels