不可解な不具合に遭遇しました。週末のスリープ状態（おそらく休止状態）からラップトップ（Windows 10）を起動すると、時計が間違っていることに気付きました。月曜日の午後1時31分でしたが、コンピューターは火曜日の午前12時27分頃だと言っていました。ええ、ネットワークエラーかもしれません。数分後にデスクに戻って、もう少し見てみると...。ある時点で午後1時43分だと気付きましたが、コンピューターは過去12分間のうち8分を失っていたかのように午前12時31分だと言っていました。https://currentmillis.com/そして驚いたことに、ミリ秒カウンタは毎秒約10ミリ秒という非常にゆっくりとした増加しかしていませんでした。（おそらく10秒間、毎秒スクリーンショットを撮りました。必要であれば提供できますが、それ以上の有用な情報は得られないと思います。）実際、また同じことが起きています。そして、Javaテストプログラムを開始し、無限whileループで と を印刷しましたSystem.currentTimeMillis()がThread.sleep(1000);、同様の動作を示しています。いくつかの数秒後にタイムスタンプの塊を吐き出します。間塊は数ミリ秒しか経過しません。投稿の最後にログを添付しました。ある時点で、正常に動作し始めました。振り返ってみると、数秒の間に時間が数時間遡っていたことに気が付きました。ほぼ正しい時刻に。私が気づいたもう 1 つのこと (現在、再び発生しています) は、異常に遅い時間帯に、Firefox、Outlook、およびデスクトップ ウィンドウ マネージャーが GPU を 100% 使用していることです。より正確な記録がないため、私が知る限り、100% GPU は時間の不正行為と正確に相関しているようです。
結局のところ、なぜこのようなことが起きたのか、あるいはどのように起こり得たのかを知りたいのです。コンピューターを再起動すると時計の異常な動作が止まるので、不具合の発生を止める方法を知る必要はありませんが、そもそもこの種の動作はほぼ不可能だと思っていました。多くのサーバー プログラムはタイムアウトに依存しており、時計が 13 分間停止すると、さまざまな他の問題が発生する可能性があります。問題を再現できるとは思えないので、それ以上のデバッグは不可能です。基本的に、同様のことを聞いたことがある人や、Windows のシステム時間メカニズムのより深い仕組みに関する知識 (私にはその知識がありません) に基づいてもっともらしい理論を思いつくことができる人がいないか知りたいのです。
記録されたタイムスタンプのサンプル:
1553575488576
1553575488584
1553575488591
1553575488599
1553575488606
1553575488614
1553575488621
1553575488628
1553575488636
1553575488643
1553575488651
1553575488658
1553575488665
1553575488673
1553575488680
1553575488688
1553575488695
1553575488703
1553575488710
1553575488717
1553575488725
1553575488732
1553575488740
1553575488747
1553575488754
1553575488762
1553575488769
1553575488777
1553575488784
1553575488791
1553575488799
1553575488806
1553575488814
1553575488821
1553575488828
1553575488836
1553575488843
1553575488851
1553575488858
1553575488865
1553575488873
1553575488880
1553575488888
1553575488895
1553575488902
1553575488910
1553575488917
1553575488925
1553575488932
1553575488940
1553575488947
1553575488955
1553575488962
1553575488969
1553575488977
1553575488984
1553575488992
1553575488999
1553575489006
1553575489014
1553575489021
1553575489029
1553575489036
1553575489044
1553575489051
1553575489058
1553575489066
1553575489073
1553575489081
1553575489088
1553575489095
1553575489103
1553575489110
1553575489118
1553575489125
1553575489132
1553575489140
1553575489147
1553575489155
1553575489162
1553575489169
1553575489177
1553575489184
1553575489192
1553575489199
1553575489206
1553575489214
1553575489221
1553575489229
1553575489236
1553575489243
1553575489251
1553575489258
1553575489265
1553575489273
1553575489280
1553575489288
1553575489295
1553575489303
1553575489310
1553575489317
1553575489325
1553575489332
1553575489340
1553575489347
1553575489354
1553575489362
1553575489369
1553575489376
1553575489384
1553575489391
1553575489399
1553575489406
1553575489413
1553575489421
1553575489428
1553575489436
1553575489443
1553575489450
1553575489458
1553575489465
1553575489473
1553575489480
1553575489487
1553575489495
1553575489502
1553575489510
1553575489517
1553575489524
1553575489532
1553575489539
1553575489547
1553575489554
1553575489561
1553575489569
1553575489576
1553575489584
1553575489591
1553575489598
1553575489606
1553575489613
1553575489621
1553575489628
1553575489635
1553575489643
1553575489650
1553575489658
1553575489665
1553575489672
1553575489680
1553575489687
1553575489695
1553575489702
1553575489709
1553575489717
1553575489724
1553575489732
1553575489739
1553575489746
1553575489754
1553575489761
1553575489769
1553575489776
1553575489783
1553575489791
1553575489798
1553575489806
1553575489813
1553575489820
1553575489828
1553575489835
1553575489843
1553575489850
1553575489857
1553575489865
1553575489872
1553575489880
1553575489887
1553575489895
1553575489902
1553575489909
1553575489917
1553575489924
1553575489932
1553575489939
1553575489946
1553575489954
1553537091156
1553537092160
1553537093161
1553537094162
1553537095163
1553537096164
1553537097164
1553537098165
1553537099174
1553537100193
1553537101196
1553537102209
1553537103214
1553537104215
1553537105216
1553537106216
1553576225618
1553576226620
1553576227623
1553576228626
1553576229628
1553576230630
1553576231632
1553576232636
1553576233639
1553576234641
1553576235644
1553576236646
1553576237648
1553576238650
編集: より多くのデータを集めてグラフにしました。青い線は、1 秒ごとに currentTimeMillis を sysout してカウントした時間の経過です。クロックが故障していたとき、ログは 7 個ほどのグループにまとまっていましたが、それでも 1 秒あたり 1 行程度だったので、x 軸は秒単位として扱うことができると思います。(最初のタイムスタンプを減算し、すべてを 41M にクリップしたので、グラフのパターンが見えています。削除した情報は特に役に立たなかったと思います。) グラフを目視すると、約 18 分のサイクルで、クロックが 5 分間正常になり (ただし、約 11 時間進んでいます)、次に 13 分間非常に遅いクロックになり、その後、数時間短時間逆戻りし、その後、遅いセグメントが発生しなかったかのようにポイントまでジャンプして進む、という状態が起こっていたようです。 (1 サイクルの平均レートを計算したところ、1003 ms/サンプルという結果になりましたが、記録されたサンプル レートと実際のサンプル レートの関係は、私自身の推定に基づいていることは認めます。それでも、クロック レートはサイクル全体で平均して正しいレートになると信じています。)
編集: 参考までに、今日またこの不具合が発生しました。おそらく関連しているのは、ラップトップを 5 日間ほどスリープ状態にしておいたのですが、次に電源を入れたときに問題が発生したということです。また、Windows 10 Enterprise、バージョン 1803、ビルド 17134.590 にも注意してください。