たとえば、Windows などの標準的な PC クロックは +/-10 ミリ秒しか正確ではないのに対し、リアルタイム システム クロックはミリ秒未満の精度であると言われている、システム クロックに関する多くの議論を見てきました。しかし、これらの主張は何を意味するのでしょうか? このタイミング変動がどの程度重要かは、クロック タイミングが測定される間隔に完全に依存します。2 つの連続するクロック呼び出しが 10 ミリ秒異なるタイムスタンプを返した場合、それは大惨事になりますが、幸いなことに、これは事実ではありません。しかし、クロックが 1 か月の間に 10 ミリ秒しか増減しない場合、それは実用的な目的にとって事実上完璧なタイミングです。質問を別の方法で提起するために、1 秒間隔で 2 つのクロック呼び出しを行った場合、たとえば標準の PC-Windows、PC-リアルタイム (たとえば、それをサポートする mb を備えた QNX)、およびマック？
2 に答える
1
あなたの質問は、より大きな議論につながる可能性があります。クロックが測定されるタイミング間隔について話しているとき、それはドリフトと呼ばれると思います。2 つの連続したクロック呼び出しからのタイムスタンプが 10 ミリ秒異なっていた場合、処理にそれほど時間がかかっている可能性があります。割り込みがあった可能性があります。クロックがひどくドリフトしている可能性があります。レポートの精度が 10 ミリ秒単位である可能性があります。丸め誤差が発生している可能性があります。システム クロックのレポート精度は、その速度 (つまり、1GHz = 1ns)、ハードウェア サポート、および OS サポートによって異なります。申し訳ありませんが、Windows と Mac の違いがわかりません。
于 2011-09-22T06:41:33.277 に答える
0
このトピックに関する特定のディスカッションにリンクしていないため、Java 側からこのトピックに関するわずかな経験しか伝えられません。
クラシックの粒度System.currentTimeMillis()は、しばらく前からかなり悪かった (Windows XP では 15ms)。これは、同じ値を返さない2 つの隣接する呼び出し間の可能な最小の差が 15 ミリ秒であることを意味します。System.currentTimeMillis()したがって、8 ミリ秒かかるイベントを測定すると、結果として 0 ミリ秒または 15 ミリ秒のいずれかが得られます。
明らかに破滅的な短い時間スパンを測定するため。より長い時間スパンを測定する場合、それは実際には問題ではありません。
これが、短い時間間隔を測定するように特別に設計されSystem.nanoTimeたJavaが導入された主な理由の 1 つであり、通常(つまり、OS がそれをサポートしている場合)、はるかに細かい粒度を持っています (私がテストしたすべてのシステムで、同じ値を 2 回返すことはありませんでした)。 、計算なしで連続して 2 回呼び出された場合でも nbetween)。
そのため、最新のコンピューターは通常、適切な API を使用すれば、非常に細かく正確な時間測定を提供できます。
于 2011-09-22T06:53:15.373 に答える