問題タブ [nanotime]

ブログ投稿Beware of System.nanoTime() in Javaに記載されているように、x86 システムでは、Java の System.nanoTime() はCPU固有のカウンターを使用して時間値を返します。ここで、通話時間を測定するために使用する次のケースを考えてみましょう。

現在、マルチコア システムでは、time1 を測定した後、スレッドは、カウンターが前の CPU のカウンターよりも小さい別のプロセッサにスケジュールされている可能性があります。したがって、time1 よりも小さいtime2 の値を取得できます。したがって、timeSpent で負の値が得られます。

この場合を考えると、System.nanotime は今のところほとんど役に立たないのではないでしょうか。

システム時刻を変更しても nanotime に影響しないことはわかっています。それは私が上で説明した問題ではありません。問題は、電源がオンになってから各 CPU が異なるカウンターを保持することです。このカウンタは、最初の CPU と比較して 2 番目の CPU で低くなる可能性があります。スレッドは、OS によって time1 の取得後に 2 番目の CPU にスケジュールされる可能性があるため、timeSpent の値は正しくなく、マイナスになることさえあります。

Java アプレットを strace しようとしていますが、strace が機能していないようです。次の関数を呼び出しています。

上記のメッセージが呼び出される直前に strace から次の出力が得られ、strace からは何も得られません。

メソッドからログ出力を取得し始めると、strace からは何も得られません。私はstraceにかなり慣れていません。何が起こっているのかについての手がかりはありますか？アプレットはトレースできますか?

タイトルはほとんど一目瞭然ですが、私はこの単純さで自殺しています。

ここを見ましたが、あまり役に立ちません。

私の友人の 1 人が彼が行ったことを見せてくれましたが、私はこれがどのように起こったのかを説明するのに深刻な途方に暮れていました.時間が経過し（その部分は Thread.sleep(1000) ）、一見永遠にかかりました（10秒待っていたものが完了するまでに約3分かかりました）。どのくらいの時間が経過したかを確認するためにミリタイムを使用してみました: 毎秒経過したナノタイムの量を出力し、毎秒、ナノタイムが毎秒およそ 40 ～ 50 ミリ秒移動していることを確認しました。

System.nanotime と Java に関連するバグを確認しましたが、nanotime が突然大きく増加してから停止するというバグしか見つからなかったようです。別の質問で読んだ内容に基づいてこのブログエントリも閲覧しましたが、それを引き起こす可能性のあるものは何もありませんでした.

明らかに、代わりにミリタイムを使用するだけで、この状況を回避できます。これには多くの回避策がありますが、私が興味を持っているのは、システム クロックに関するハードウェアの問題以外に、または少なくとも CPU が持つ最も正確なクロック以外に何かがあるかどうかです (それが System.nanotime が使用しているように見えるため)。このように一貫して遅く実行される可能性がありますか?

secondsNano は 0.04 のラインに沿って何かを出力しますが、secondsMili は 1 に非常に近い値を出力します。

この行に沿ったバグがSun のバグ データベースで報告されているようですが、重複としてクローズされましたが、既存のバグへのリンクはありません。これは非常にシステム固有であるように思われるため、これがハードウェアの問題であることがますます確実になっています。

2つのイベント間の経過時間をナノ秒単位でカウントしたいと思います。そのために、ここでSystem.nanoTime()説明したように使用できます。問題は、2つのイベントが異なるスレッドで発生していることです。

nanoTime()は絶対タイムスタンプを返さず、代わりに時間差の計算にのみ使用できるため、2つの異なるスレッドで取得した値が、2つのイベント間で経過した物理時間と一致しているかどうかを知りたいです。

私自身と私の時代の別の開発者は、最近、仕事中のCore2Duoマシンから新しいCore2Quad9505に移行しました。どちらもWindowsXPSP332ビットとJDK1.6.0_18を実行しています。

そうすると、System.nanoTime（）から戻ってくるばかげた値のように見えるため、いくつかのタイミング/統計/メトリック集約コードの自動化された単体テストがすぐに失敗し始めました。

私のマシンでこの動作を確実に示すテストコードは次のとおりです。

典型的な出力：

100倍実行すると、実際の睡眠時間の33％から60％のナノ結果が得られます。通常は約40％です。

Windowsのタイマーの精度の弱点を理解し、System.nanoTime（）のような関連スレッドをスレッド間で一貫して読んだことがありますか？ただし、私の理解では、System.nanoTime（）は、使用している目的を正確に目的としています。経過時間の測定。currentTimeMillis（）よりも正確です。

なぜそれがそのようなクレイジーな結果を返すのか誰かが知っていますか？これはハードウェアアーキテクチャの問題である可能性がありますか（変更された唯一の主要なものはこのマシンのCPU /マザーボードです）？現在のハードウェアでのWindowsHALに問題がありますか？JDKの問題？nanoTime（）を放棄する必要がありますか？どこかにバグを記録する必要がありますか、それともさらに調査する方法についての提案がありますか？

UPDATE 19/07 03:15 UTC：以下のfinnwのテストケースを試した後、さらにグーグルを実行し、 bugid：6440250などのエントリに出くわしました。また、金曜日の終わりにpingがネガティブに戻ってきていることに気付いた他の奇妙な行動を思い出しました。そこで、boot.iniに/ usepmtimerを追加すると、すべてのテストが期待どおりに動作し、pingも正常になりました。

しかし、なぜこれがまだ問題であったのかについて少し混乱しています。私の読書から、TSCとPMTの問題はWindowsXPSP3でほぼ解決されたと思いました。私のマシンが元々SP2であり、元々SP3としてインストールされていたのではなく、SP3にパッチが適用されていたことが原因でしょうか？また、 MSKB896256のようなパッチをインストールする必要があるかどうかも疑問に思います。たぶん私はこれを企業のデスクトップビルドチームに取り上げるべきでしょうか？

リクエストの長さを監視するフィルターを作成しました。

これからミリ秒数を取得するにはどうすればよいですか?

これはPHPでも可能ですか？

そうでない場合、利用可能な最高精度はどれくらいですか?

大きなナノ秒の値をミリ秒とナノ秒に変換する最も正確な方法は、ナノ秒の上限が 999999 であることに疑問を抱いています。目標は、ナノ秒とミリ秒の値を組み合わせて、制限で可能な最大の解像度を確保することです。与えられた。これは、スリープ/待機メソッドや、大きなナノ秒値を提供する他の外部ライブラリとの比較のためです。

編集:私のコードは次のようになります:

乾杯、クリス

asmのJavaバイトコード計測を使用して、特定のバイトコード（元のコードにメイン機能を持つクラスファイル）ランタイムを測定する方法があるかどうか疑問に思っていました.

測定値は可能な限り正確である必要があり、可能であればナノ秒単位である必要があります。

ありがとう