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>