Issue in waking up of device at Accurate Time After sleep.

Question

Hi Below is the code i am using to waking up my device:

Device : INTEL NUC device

Windows : Windows 10 Enterprise

version: 21H2

OS Build: 19044.2604

A. For short duration(when wake is schedule after 2-3 mins) it is accurate.

B. But if it is schedule for wake after long time (1-1.5 days after) : It takes around 10-15min after delay to wake up.

C. But if it is schedule for wake after more longer time(> 2 days after): It takes around 40-50 mins after delay to wake up.

Can you tell why is it so ? Is it due to quartz clock or system clock not sync?

Pls help to debug it

On both devices S3 sleep state is present (Hibernate ,S0(modern standby ,hybrid sleep are disabled).

using Signage.DataModel;
using Signage.Service;
using Signage.Views;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.InteropServices;
using System.Text;
using System.Threading.Tasks;
namespace Signage.Utilities
{
    public class TaskScheduler
    {
        public delegate void TimerCompleteDelegate();
        private static readonly log4net.ILog Log = log4net.LogManager.GetLogger(typeof(TaskScheduler));
        public static void completionRoutine()
        {
            Log.Info(".................................... complete .................");
        }
        [DllImport("kernel32.dll", SetLastError = true)]
        static extern IntPtr CreateWaitableTimer(IntPtr lpTimerAttributes, bool bManualReset, string lpTimerName);
        [DllImport("kernel32.dll", SetLastError = true)]
        static extern bool SetWaitableTimer(IntPtr hTimer, [In] ref long pDueTime, int lPeriod, TimerCompleteDelegate pfnCompletionRoutine, IntPtr pArgToCompletionRoutine, bool fResume);
        [DllImport("kernel32.dll", SetLastError = true)]
        public static extern bool CancelWaitableTimer(IntPtr hTimer);
        [DllImport("powrprof.dll", SetLastError = true)]
        [return: MarshalAs(UnmanagedType.Bool)]
        private static extern bool SetSuspendState(bool hibernate, bool forceCritical, bool disableWakeEvent);
        private static IntPtr handle;
        static bool isNull = true;
        public static bool Hibernate()
        {
            return SetSuspendState(true, false, false);
        }
        public static void DisposeAndUpdateAppView()
        {
            StoredCredentialModel.GetInstance().IsAppInSleep = true;
            AppState.GetInstance().DisposeDisplayUI();
           
        }
        public static bool Sleep()
        {
            // DisposeAndUpdateAppView();
            Log.Info("device is on sleep mode ");
            return SetSuspendState(false, false, false);
        }
        public static IntPtr SetWakeAt(DateTime dt)
        {
            TimerCompleteDelegate timerComplete = new TimerCompleteDelegate(completionRoutine);
            // read the manual for SetWaitableTimer to understand how this number is interpreted.
            long interval = dt.ToFileTimeUtc();
            if (isNull)
            {
                handle = CreateWaitableTimer(IntPtr.Zero, true, "WaitableTimer");
                isNull = false;
            }
            SetWaitableTimer(handle, ref interval, 0, null, IntPtr.Zero, true);
            return handle;
        }
    }
}

Answer 1

Hello Vishal2 Bansal,

Just to add to the AI answer, the proportional scaling you're seeing (10–15 min over 1–1.5 days, 40–50 min over 2+ days) points more specifically to RTC (hardware real-time clock) crystal drift. During S3, the OS is offline and only the onboard RTC oscillator tracks time. Its drift accumulates linearly over the sleep duration, which matches your pattern closely.

You can verify this right after a long wake, before NTP resync kicks in:

w32tm /query /status

A large offset there confirms RTC drift as the primary driver.

As a mitigation, consider scheduling intermediate wakes every few hours, running w32tm /resync to reset the clock, then re-arming your SetWaitableTimer for the next target. This keeps the drift accumulation window short and your wake timing much tighter.

Answer 2

The behavior is expected and is caused by timer and platform power‑management characteristics, not by your code logic or a simple clock drift.

Key points from the platform behavior:

1. How wake timers work
   • For S3/S4, Windows uses a waitable timer (as in your code) to program a hardware wake event (typically via RTC/ACPI wake alarm).
   • SetWaitableTimer with fResume = TRUE is the correct way to request a wake from sleep/hibernate.
   • The OS and firmware are allowed to deliver the wake later than the requested absolute time; the timer is only guaranteed to be detected on or after the next system clock tick once the platform is active again.
   • The underlying system clock granularity and interrupt latency limit how precisely expiration is detected. For long delays, other power‑management policies and hardware behavior add more variability.
2. Timer accuracy limitations
   • Timer expiration is only accurate to the granularity of the system clock. The OS checks for expiration on each clock tick; if the tick is delayed by other interrupts, the timer can be detected later.
   • For absolute times, expiration is detected on the first tick after the requested time; for relative times, expiration can be up to one clock period early or late.
   • Reducing the clock period to improve accuracy increases power consumption and still cannot guarantee perfect timing if other device interrupts delay the clock interrupt.
   • Over long intervals (1–2 days), small inaccuracies and platform policies accumulate, so the actual wake can be noticeably later than the requested time.
3. System sleep/hibernate and idle policies
   • On a traditional PC, when the “Put the computer to sleep” timer expires, the system enters S3; when “Hibernate after” expires, it wakes from S3 and immediately enters S4.
   • When the system wakes automatically (for a scheduled event), Windows sets an unattended idle timer (at least 2 minutes) to allow apps to call SetThreadExecutionState and keep the system awake if needed.
   • These idle timers and transitions are optimized for power saving, not sub‑minute accuracy over multi‑day intervals.
4. Why short delays look accurate but long ones do not
   • For short delays (2–3 minutes), the RTC and system clock drift are negligible, and the platform is likely still in a relatively simple low‑power state path, so wake appears “on time.”
   • For 1–2+ day delays, the following factors can introduce tens of minutes of delay:
     • RTC and platform power‑management policies (firmware may coalesce or adjust wake events).
     • System clock granularity and delayed interrupt handling.
     • Interactions with other scheduled maintenance or wake events.
   • This is not primarily a quartz/RTC failure; it is the combination of hardware/firmware wake behavior and OS timer granularity.
5. Debugging/mitigation guidance Within the constraints of the platform, the following can be checked:
   • Verify that S3 is indeed used and that hibernate/Modern Standby are disabled as intended.
   • Check whether other scheduled wake timers (for example, maintenance tasks) exist using powercfg /waketimers and whether they interact with the requested wake.
   • Review device wake capabilities and ACPI support on the NUC (for example, which devices can wake from S3 and how the BIOS exposes RTC/ACPI wake alarms).
   • Be aware that Windows does not guarantee exact multi‑day wake timing from S3/S4; the observed 10–50 minute delays are consistent with documented timer and power‑management limitations.

There is no indication from the platform documentation that this behavior can be fully eliminated in application code; it is a consequence of system timer accuracy and power‑management design.

---

References:

• System Wake-up Events
• Timer Accuracy
• Display, sleep, and hibernate idle timers