2012-01-18 10 views
1

私はUbuntu 10.10マシン上の複数のソースからプログラムのパフォーマンスについてプログラム的にデータを収集しようとしています。他のすべてのソースについて、私はRDTSC x86命令を使ってそれらを集め、gettimeofdayを使って絶対時間で秒に変換することができました。しかし、これらのデータソースと、/ sys/kernel/debug/tracingでのsched_switchトレースの出力を調整しようとすると、何か不明な時間から、私が見ている出力は秒とマイクロ秒です。/sys/kernel/debug/tracing from Ubuntu

手順私は既に行っています:
1. Linuxカーネルは内部的にRDTSCも使用していると判断しましたが、収集するオフセットを追加しましたが、取り出せる能力がないようです。これはコア単位でも行います。つまり、4つのコアすべてを試して、最適なものを決定しなければならないということです。これは、この問題の解決策のように思われます。
2.少なくとも変換自体が一貫しているかどうか(つまり一定のオフセットがあるかどうか)を確認するため、RDTSCの変換を試みましたが、スケールは実行中一定ではないようです。
3. clock_gettime(CLOCK_MONOTONIC、...)は非常によく似た値を持つようですが、常に不安定な量(約0.5秒)で消えてしまいます。

他のデータソースが必要なものに時間を集める方法を変更することができれば、トレースの時間と収集している時間を調整するために時間を収集する必要があります?出力をRDTSCに変更する方法はありますか?それでは、それを使うことができますか、または出力するものと同じ時間を得るためのシステムコールがありますか?助けを前にありがとう。

答えて

0

ので、ソースコードを見た後、私はクロック周波数を掛けしようとする一点で、コードはRDTSC値を取り、それをいくつかの空想の数学をしていることを発見し、起動時に計算されるオフセットを追加してください。しかし、RDTSCは新しいチップのコア間で一貫性があることが保証されているので、このコードは少し古くなっているようですが、これはそれぞれが異なると仮定しています。また、最大周波数の代わりに現在の周波数を集めているように見えました。これは、RDTSCが使用していると書かれているようです。

このように、この時点では、時間は実際の時間と直接関連しているとは思われません。うまくいけば、このバグは今後のカーネルリリースでこれを修正するために修正され、私はこれらの2つのセットを同期させる機会を開くが、それまでは十分に信頼できないように思われる。

0

RDTSCは一般的な命令ではありません。それを使用するときいくつかの問題がありますが、hybernationのようないくつかのイベントはカウンターをリセットします。問題の他の一般的なソースは、動的CPUであるclock.ThereはRDTSCとHPETを比較する良い記事です:

http://aufather.wordpress.com/2010/09/08/high-performance-time-measuremen-in-linux/

RDTSCの精度を確認するために、私はそれが1秒間にカウントし、宣言とそれを比較どのように多くのクロックサイクルを測定しますCPUクロック。これは、CPUの動的クロックが無効の場合にのみ機能します。参照:

https://github.com/petersenna/rdtscbench

+0

ここでの問題はRDTSCではなく、実際には数秒の間に数マイクロ秒の精度でそれを得ることができました。ソースコードを見た後、ログの時刻は実際にはRDTSCに基づいているので、これは問題ではありません。 –