ロケールとタイムゾーンは正確ですが、ハードウェアとシステムクロックは起動するたびに約7分ずつオフセットされます。

ロケールとタイムゾーンは正確ですが、ハードウェアとシステムクロックは起動するたびに約7分ずつオフセットされます。

アーチを始めるたびに時間が数分ずつ遅くなるのを感じます。 RTC時間はオフになり(私が知っている限り「ドリフト」されています)、ハードウェアクロックに影響を与えます。

$ 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

編集するこの記事を書いている間、私はこの線の上の時間値が他の線と一致することに気づいていませんでした。しかし、私の時計とスマートフォンの時間には、前述の7分というオフセットがあります。

私のロケール:

$ 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=

これまで、私はhwclock --hctosysマニュアルページの内容を使用することを非常に消極的でした。

実行中のシステムではこの機能を使用しないでください。システム時間をスキップすると、ファイルシステムのタイムスタンプが破損するなどの問題が発生する可能性があります。また、NTPの「11分モード」などのハードウェアクロックが変更されると、--hctosysはドリフト補償を含む時間を誤って設定します。

私が知る限り、Windows 10を正しく設定しました。。何か抜けましたか?それとも時計を正しく設定していませんか?

編集2リクエストに応じてコンテンツ/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

答え1

実際の時間と開始時のRTC間の時間差が大きい場合、NTPは時間の経過とともにゆっくりと増分するのではなく、開始後に一度にすべて余分に補償するように設定できます。

ファイルに最初の行を追加します/etc/ntp.conf(最初の行でなければなりません)。

tinker panic 0

Tinker Panic - パニックしきい値を秒単位で指定し、デフォルトは1000秒です。 0 に設定すると、パニックの健全性チェックが無効になり、すべての値のクロックオフセットが許可されます。

これにより、現在のLinux時間の問題が解決される可能性がありますが、時間の経過とともに2つのオペレーティングシステム間の時間差が発生する根本的な原因も調査します。

答え2

コマンドは、timedatectl「世界時」(つまりカーネルのUTCの概念)と「RTC時間」が同期していることを報告しているため、リアルタイムクロックはUTC時間であり、起動時の時間はRTCからカーネル時計に正常に送信されました。時間。

しかし、それが本当であるSystem clock synchronized: noことを示しています。ntpdいいえ同期が成功した理由は、実際の UTC がシステムで想定した UTC とあまりにも異なるためです。 Rui F. Ribeiroの答えは、この問題を解決することを目指しています。

このファイルの内容を確認する必要があります/etc/adjtime。最初の行には、スペースで区切られた3つの値を含める必要があります。 1つ目は、1日に秒単位でバッテリ駆動RTCの仮定されたシステムドリフト速度です。 2番目の値は、最新のRTCドリフト調整時間のUNIXタイムスタンプです。

ドリフト速度が間違っていると(おそらく実行時に他のオペレーティングシステムによってRTCが調整され、RTCドリフトで誤って検出されたため)、起動時に7分のエラーが発生する可能性があります。

バッテリ対応RTCからコアクロックに時間をコピーすると、起動時にドリフト速度の修正が適用されるため、誤ったドリフト速度に起因するエラーもコアクロックに伝播する可能性があります。これは、2つのクロックが互いに同期していますが、実際のUTCで7分の差がある理由を示しています。これはまた、ランニングがhwclock --hctosys問題を解決しないことを意味します。

ドリフト速度が/etc/adjtime異常に大きい場合は、誤ったドリフト速度の修正によって時計が調整されるのを防ぐために、これをゼロに設定するか、ファイル全体を消去する必要があります。システムクロックがNTPと同期している場合、通常はバッテリ対応RTCにも同期時間が伝播します。

「コールド」ドリフトの割合(つまり、システムがオフになっている場合や他のオペレーティングシステムを実行しているときに発生するドリフト)の自動補償を設定するには、/etc/adjtime次の手順を使用できます。

1.) 起動スクリプトと終了スクリプトをチェックして、システムクロックまたはバッテリーサポート RTC が実行されているすべてのポイントを理解していることを確認します。

2.)比較的長いシステムダウンタイム(少なくとも4時間、一晩、または週末が良い)を選択してください。その後、すべての自動NTP同期を一時的に無効にします。 initramfsスクリプトも含まれていることを確認してください。

3.)システムをシャットダウンする前に、システムクロックの時刻が正しいことを確認してから実行してください> /etc/adjtime; hwclock --systohc --utc --update-drift/etc/adjtimenowが0.0最初の行の最初の値で、現在のUnixタイムスタンプが最初の行の2番目の値、+が2行目の唯一の値、3行目が表示されていることを確認しますUTC。その後、システムをシャットダウンします。

4.) システムを再起動した後、ntpdateまたは他の方法を使用してください。コアクロックのみ設定システムが正しいUTC時間を取得するようにしてください。その後、もう一度実行してくださいhwclock --systohc --utc --update-drift。最初の値は、/etc/adjtimeシステムがダウンしたときにRTCがドリフトする速度と一致するように更新する必要があります。

5.)次に、NTP同期システムで自動的に実行される起動/停止/クローン操作がないことを確認します。次hwclock --update-driftの場合にのみドリフト速度を更新できます。確かに知ってくださいドリフト率の推定に使用した期間中にRTCを調整できるものはありません。

6.) 最後に、NTP 同期を再度有効にします。複数のオペレーティングシステムでデュアルブートする場合は、理想的には1つのオペレーティングシステムだけがRTCを調整する必要があります。それ以外の場合、ドリフト速度の推定は不正確になります。

答え3

最近Linuxカーネルをチェックしていませんが、古いカーネルにはシステムタイム(RAM)でRTCを更新する非常に奇妙なコードがあります。私は数年前にこの問題を解決しようとしましたが、コードはカーネルに含まれていませんでした。

現在のシステムは、シャットダウンまたは再起動(有効になっている場合)でシステム時間からRTCを更新すると思います。

ディストリビューションがメカニズムを提供していない場合は、cronジョブ(またはsystemdタイマー)を追加してRTCを定期的に更新できます。

関連情報