Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Mar 2017 19:59:57 -0400
From:      Prakhar Goel <newt0311@gmail.com>
To:        Colin Percival <cperciva@tarsnap.com>
Cc:        freebsd-cloud@freebsd.org
Subject:   Re: Issues with clock skew on GCE
Message-ID:  <CABa1M20enPzknAk-NJZuiFpkm86StWMS1B6nAiXdKC6pzj=kDg@mail.gmail.com>
In-Reply-To: <CABa1M21T4LDNQqXWS3NgA_sJJDcJCErA6=Rg3=YvVz6P20vZrw@mail.gmail.com>
References:  <CABa1M210%2B%2BioEM5LQ=Lx%2Brbsn3d4bWLojUc4T3WusOH7t-g4cg@mail.gmail.com> <0100015b075efd74-2a227e8b-7fc9-4ebb-9187-f549733c1b6c-000000@email.amazonses.com> <CABa1M21T4LDNQqXWS3NgA_sJJDcJCErA6=Rg3=YvVz6P20vZrw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Just to close this issue out:

The solution I went with was to switch the kernel timecounter to
ACPI-fast. I ran a check on this* and whatever the drift, it was small
enough for the ntpd process to keep the system clock sync'd (drift
less than 0.001s after a day). As a control, I ran the same test on a
VM using the TSC (default) timecounter and that machine drifted by ~50
seconds every five minutes (!).

Thanks for your help Colin and Bruce.

* Just calling ntpdate every five minutes and logging the results. The
specific command I used was ntpdate -q metadata.google.internal so it
didn't actually update the system clock, just checked the drift
against the Google time-servers.
--
________________________
Warm Regards
Prakhar Goel



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABa1M20enPzknAk-NJZuiFpkm86StWMS1B6nAiXdKC6pzj=kDg>