# Clock drift after suspend to RAM (S3) [SOLVED]

## fr4nk

Hi,

My problem:

Whenever my machine goes into standby using suspend to RAM, the clock seems to drift away into the past (about 1 minute of drift per 10 minutes of real time). ntpd is running and working correctly until resuming from standby.

I can sync time by running `ntpclient europe.pool.ntp.org`, but after a few seconds the drift already leaves my clock one second behind.

This does not occur when using hibernation (suspend to disk).

Syslog doesn't say one line related to this problem.

My setup:

Gentoo ~amd64

Kernel 2.6.28-gentoo

I don't use suspend2/tuxonice, but `echo mem > /sys/power/state`

I'm using `ssh anotherhost date && date` to compare current system date with that of another ntp-sync'd machine.

Has anyone run into this problem before? I don't always want to use hibernation (for speed reasons).   :Confused: Last edited by fr4nk on Sat Mar 07, 2009 8:47 pm; edited 1 time in total

----------

## VinzC

Try running ntpq -p to tell if ntpd is still in sync with the remote clock source.

----------

## fr4nk

Thanks for your reply.

 *VinzC wrote:*   

> Try running ntpq -p to tell if ntpd is still in sync with the remote clock source.

 

I tried that before, however the problem doesn't seem to be ntp related at all, more of a general clock problem. If I start the machine w/o ntp, the clock remains in sync, if I suspend to RAM without ntpd running, the drift returns just as with ntpd...

Here is the output of ntpq -p nonetheless:

Before suspend:

```
     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

+pils.linux-kern 129.132.2.21     3 u   31   64  377   18.984   -3.705   5.352

+web04.mediainve 213.9.73.106     3 u   12   64  377   17.183    1.536  12.499

*asteria.debian. 193.204.114.233  2 u    3   64  377   17.622   -1.167  18.539

+pluto4.fips.at  131.130.1.11     3 u   10   64  377   17.027   -0.006  15.160
```

after a few minutes:

```
     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

 85.124.60.70    213.10.47.241    2 u    7   64   37   45.199  13612.1 11822.1

 mail.rettenstei 212.6.108.160    2 u    6   64   37   66.150  13725.4 11906.5

 ntp.inode.at    195.113.144.201  2 u    4   64   37   16.786  13894.8 11975.4

 portal2.theater 192.168.103.101  3 u    4   64   37   19.211  13895.4 11944.7
```

Seems to communicate with the peers, but doesn't do something about the drift (a manual ntpdate resets the clock as mentioned, but also keeps the drift)

----------

## VinzC

There have been r1 and r2 updates to gentoo-sources-2.6.28 since. Have you tried them? I don't use suspend anyway so can't tell accurately.

----------

## fr4nk

Kernel update didn't work, neither did setting system clock to hardware clock before suspend and restoring it later (and vice versa).  :Confused: 

----------

## doctork

I modified /etc/pm/config.d/gentoo to look like this:

```
cat /etc/pm/config.d/gentoo

NEED_CLOCK_SYNC=TRUE

HOOK_BLACKLIST="01grub 55NetworkManager 90clock"

```

and  added this to /etc/pm/sleep.d (cribbed for /usr/lib64/pm-utils/sleep.d/90clock):

```
cat /etc/pm/sleep.d/91clock

#!/bin/sh

# Synchronize system time with hardware time.

# TODO: Do modern kernels handle this correctly?  If so, we should detect that

#       and skip this hook.

. "${PM_FUNCTIONS}"

suspend_clock()

{

#       /sbin/hwclock --systohc >/dev/null 2>&1 0<&1

        /etc/init.d/ntp-client stop

        /etc/init.d/ntpd stop

}

resume_clock()

{

#       /sbin/hwclock --hctosys >/dev/null 2>&1 0<&1

        /etc/init.d/ntp-client start

        /etc/init.d/ntpd start

}

[ "$NEED_CLOCK_SYNC" ] || exit $NA

case "$1" in

        hibernate|suspend) suspend_clock ;;

        thaw|resume) resume_clock ;;

        *) exit $NA ;;

esac

```

It seems to work.  I don't know what dire effects might appear if access to NTP servers isn't available.

--

doc

----------

## Akkara

It is possible a stale /etc/adjtime might be affecting your clock.  It is OK to remove it (it'll get regenerated).

----------

## fr4nk

Unfortunately, none of your suggestions worked. I guess the problem is either my hardware or some incompatibility between it and the kernel, since the same setup works flawlessly on my laptop.

----------

## VinzC

In this case you might try older kernels, especially those that are marked stable. If all of these fail, then it most probably is your hardware. I'm not sure but maybe fixing your laptop's DSDT might help.

EDIT: This also might help to include a custom DSDT in the kernel.

----------

## fr4nk

Alright, got it working. Seems my BIOS version was somehow defunct. Flashed an unofficial release today and the drift is gone.   :Laughing:  It doesn't seem that DSDT was the problem, since I'm still overriding it with a corrected version (and I'm doing that since before the flash and it didn't help).

The machine is a desktop btw, not a laptop (DFI lanparty w/ an nForce 4)

Thanks for all your help   :Smile: 

----------

## VinzC

Glad you solved the problem  :Smile:  .

----------

