2

組み込み Linux 環境で、Zigbee デバイスのペアリング/バインディングに関連する非常にタイミングに敏感な問題をデバッグしています。

私たちのアーキテクチャは、データが SPI インターフェイスを介して Zigbee フロント エンド モジュールから読み取られ、処理のためにカーネル空間からユーザー空間に渡されるようなものです。処理されたデータと応答はカーネル空間に戻され、SPI インターフェイスを介して再びクロックアウトされます。

Zigbee 802.15.4 のタイミング要件では、19.5 ミリ秒以内に応答する必要があると指定されており、このウィンドウのすぐ外側で応答する状況が頻繁に発生し、ネットワークで障害やパケット損失が発生します。

Linux カーネルはプリエンプションが有効な状態で実行されておらず、プリエンプションも有効にできない可能性があります。
私の疑いでは、カーネルはプリエンプティブルではないため、ioctl() インターフェイスを使用している別のタスク/プロセスがあり、これが Zigbee アプリケーションを 19.5 ミリ秒のウィンドウを超えるのに十分な時間遅らせているのではないかと考えています。

私は次のツールを試しました

  • oprofile - システム全体をプロファイリングするため、ここではあまり役に立ちません。この間、アプリケーションは少量のデータを移動するため、実際にはそれほどビジーではありません。
  • strace - オーバーヘッドが多すぎます。使用経験があまりないので、出力を改善できるかもしれません。オーバーヘッドがパフォーマンスに大きく影響するため、アプリケーションはまったく機能しません

このようなシステムをプロファイリングする他の軽量な方法はありますか?

別のタスク/スレッドでioctl呼び出しが保留されているときにキャッチする方法はありますか? （これが問題の根本原因であると仮定します）

4

2 に答える 2

1

良い質問。これがアイデアです。プロファイリングとは考えないでください。行為でそれをキャッチすることを考えてください。

16.5 ミリ秒間隔後にオフになるウォッチドッグ タイマーの作成を調査します。成功したら、タイマーをリセットします。そうすれば、障害が発生した場合にのみオフになります。その時点で、プロセスのスタック サンプル、またはそれをブロックしている可能性のある別のプロセスを取得しようとします。

これは、この手法の適応です。多少の作業は必要ですが、インサーキット エミュレータ以外に、何が起こっているかを正確に教えてくれるツールがあれば驚くでしょう。

于 2014-08-12T19:04:17.960 に答える
0

LTTng はあなたが探しているツールです。Oprofile と同様に、システム全体をプロファイリングしますが、各プロセスとカーネル スレッドで何が起こっているかをタイムライン形式で正確に確認できます。関心のある時点、つまり Zigbee の締め切りに間に合わなかったときのスレッドとスケジューラの相互作用を表示できます。抜け落ちたパケットを検出したら、巧妙に LTTng トレースをトリガーする (または停止する可能性が高い) 方法を使用する必要があるかもしれません。トレースを停止します。

たとえば、1) カーネルがまだ LTTng を実行していない場合はカーネルで LTTng を実行できるようにすること、および 2) 使用方法を学習することなどに、いくらかの時間とエネルギーを投資する必要があります。これは強力なツールであり、さまざまなプロファイリングおよび分析タスクに役立ちます。オプションがある場合、ほとんどの商用組み込み Linux ベンダーは、完全なエンド ツー エンドの LTTng 製品と構成を提供しています。そうでない場合は、オンラインで役立つヘルプと例をたくさん見つけることができるはずです。LTTng は非常に長い間存在しています。ハッピーハンティング！

于 2014-08-14T12:44:52.737 に答える