2

On each boot into Arch, I see that the time is off by a few minutes. The RTC time is off (as far as I understood, it has "drifted".) and affects the hardware clock.

$ timedatectl status
                      Local time: Mo 2018-02-12 12:45:18 CET
                  Universal time: Mo 2018-02-12 11:45:18 UTC
                        RTC time: Mo 2018-02-12 11:45:18
                       Time zone: Europe/Berlin (CET, +0100)
       System clock synchronized: no
systemd-timesyncd.service active: no
                 RTC in local TZ: no

EDIT Upon writing this post, I did not realize that the time values above this line are coherent to another. However they have an offset to my watch and smartphone time which is the aforementioned 7 minutes.

And my locale:

$ locale
LANG=de_DE.utf8
LC_CTYPE="de_DE.utf8"
LC_NUMERIC="de_DE.utf8"
LC_TIME="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_PAPER="de_DE.utf8"
LC_NAME="de_DE.utf8"
LC_ADDRESS="de_DE.utf8"
LC_TELEPHONE="de_DE.utf8"
LC_MEASUREMENT="de_DE.utf8"
LC_IDENTIFICATION="de_DE.utf8"
LC_ALL=

So far I am very reluctant to use hwclock --hctosys as the man page states:

This function should never be used on a running system. Jumping system time will cause problems, such as corrupted filesystem timestamps. Also, if something has changed the Hardware Clock, like NTP's '11 minute mode', then --hctosys will set the time incorrectly by including drift compensation.

As far as I can tell, I configured Windows 10 correctly. Is there something I am missing or did I not set the clock up correctly?

EDIT 2 Upon request, the contents of /etc/ntp.conf:

# Please consider joining the pool:
#
#     http://www.pool.ntp.org/join.html
#
# For additional information see:
# - https://wiki.archlinux.org/index.php/Network_Time_Protocol_daemon
# - http://support.ntp.org/bin/view/Support/GettingStarted
# - the ntp.conf man page

# Associate to Arch's NTP pool
server 0.arch.pool.ntp.org
server 1.arch.pool.ntp.org
server 2.arch.pool.ntp.org
server 3.arch.pool.ntp.org

# By default, the server allows:
# - all queries from the local host
# - only time queries from remote hosts, protected by rate limiting and kod
restrict default kod limited nomodify nopeer noquery notrap
restrict 127.0.0.1
restrict ::1

# Location of drift file
driftfile /var/lib/ntp/ntp.drift
  • Windows will use an NTP daemon by default which will automaticly re-sync your system clock with one on the internet. Linux might not have this switch on by default. It depends on distribution. Is it 7 minutes regardless of how long you left it switched off? Does booting windows in-between booting linux make a difference? Either way, look into installing ntp or ntp-date. These will allow your linux machine to automatically correct it's HW clock error. NTP will actually monitor for drive and adjust for it. – Philip Couling Feb 12 '18 at 11:46
  • Would you please add your /etc/ntp.conf file to the answer? – Rui F Ribeiro Feb 12 '18 at 12:06
  • "Is it 7 minutes regardless of how long you left it switched off? " Yes. Can't answer the other questions yet. @couling – henry Feb 12 '18 at 12:12
  • @RuiFRibeiro Info added! – henry Feb 12 '18 at 12:14
  • @henry Has my answer helped? – Rui F Ribeiro Feb 12 '18 at 13:27
0

If you have a larger time difference between the real time and your RTC as you have when booting, you can configure NTP to over compensate for that in one go after start, instead of doing it slowly and incrementally over time.

I would add to your /etc/ntp.conf file as the first line (it has to be the first line):

tinker panic 0

tinker panic - Specifies the panic threshold in seconds with default 1000 s. If set to zero, the panic sanity check is disabled and a clock offset of any value will be accepted.

Whilst this may solve the Linux time problem in the present, I would also investigating over time the underlying causes of the time drift between the two OSs.

  • 1
    The OP should keep this setting until the clock of his machine is in sync, then replace it with tinker panic 300 or a similar value to avoid big clock drifts. – dr01 Feb 12 '18 at 14:13
  • 1
    Ever since I installed a certain Windows 10 update (I do not recall its specific name unfortunately), the hwc offset was corrected. Wish I could tell you more than that, but I am happy that it works again... on its own. :) – henry Nov 23 '18 at 9:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.