18

セットアップは次のとおりです... システムは、個別のメッセージ (通常、メッセージあたり 32 ～ 128 バイト) を含むデータ ストリームを受信して​​います。処理パイプラインの一部として、各メッセージは 2 つの物理的に分離されたアプリケーションを通過します。これらのアプリケーションは、低レイテンシのアプローチ (UDP を介したメッセージングなど) または RDMA を使用してデータを交換し、最終的に同じメカニズムを介してクライアントに送信されます。

ワイヤ プロトコル分析を含む任意のレベルで自分自身を注入できると仮定すると、システムのレイテンシを測定するためにどのツールや手法を使用しますか。この一環として、システムに配信されるすべてのメッセージは、対応する (ただし同等ではない) メッセージがシステムを介してプッシュされ、クライアントに配信されると想定しています。

このような市場で私が見た唯一のツールは、TS-Associates TipOff です。適切なアクセス権があれば、おそらくワイヤ分析ツール (ala wireshark) と適切なディセクタを使用して同じ情報を測定できると確信していますが、これは正しいアプローチですか、それとも私が使用できるコモディティ ソリューションはありますか?

4

4 に答える 4

9

最後の段落は、それを行う必要がある典型的な方法です。この分野の通常の容疑者 (少なくとも私が市場データ (ウォール街) の待ち時間について知っている限り) は次のとおりです。

  • TSA（TSアソシエイツ）
  • コレリックス
  • コービル
  • Napatech (ハードウェア キャプチャ デバイス)
  • Endace (ハードウェア キャプチャ デバイス)

最近、VC の資金 (400 万?) を使い果たした経営の悪い会社がもう 1 つあります。

さまざまな形式に処理されるデータ (たとえば、ダイレクト エクスチェンジ フィード、RMDS、またはプロトコルを変更するその他のサーバーで) の場合、メッセージを関連付けるためにペイロードを解析できる必要があります。データ ベンダーがメッセージ定義を公開しない場合があるため、難しい場合があります。

クライアントがこれらを見ることができるように、タイムスタンプを含むペイロード情報を挿入するハードウェア デバイスがあると思います。もちろん、別の投稿者が指摘したように、時間の問題は非常に重要です。すべてのデバイスとクライアントは、時間の基準点が同じである必要があります。正確でなければならない...

私が最後に TSA と話したとき、4 つの観測点を備えた設備は約 15 万ドルでした。上に挙げた他のものも価格的には似ていると思います。

上記のハードウェア カードは、約 2,000 ドル (ベア ボーン カードの場合) から始まり、そこから (大幅に) 値上がりします。

ソフトウェアでそれを行うには、pcap (または同様のもの) を使用するクライアントを用意し、ペイロードを調べてそれらを一致させる必要があります。場合によっては、これを決定論的にするのが難しい場合があります。特に「セッション」の開始時や、メッセージが 1 つのパイプから欠落している場合などです。通常、何かに一致しない場合は、ある程度のしきい値の後、それをドロップします。

編集：免責事項：私も現在ベンチャーの一員であり、それを開示する必要があります.

于 2009-08-05T21:59:04.957 に答える
4

最近の論文が役に立つかもしれません (また、ハードウェア ベースのソリューションよりもはるかに安価です)。クロック スキューをかなり正確に説明する方法もあります。最後に一方向レイテンシ測定の研究を真剣に調べたとき (数年前)、最も正確な手法はSue Moon による線形計画法アルゴリズムでした (参照コードはこちらから簡単に入手できます)。)、しかし、いくつかの最新の線形計画法を使用しないと、オンライン アルゴリズムとして実行することはかなり非現実的です。1 日を通して定期的に計算を行わずにタイムスタンプを記録し、その後、蓄積されたデータに対して LP アルゴリズムを実行することをお勧めします。オンラインで実行できるほど迅速な手法は他にもいくつかありました ( Vern Paxson による独創的な論文を含む) が、それらはすべて正確性がはるかに劣っていました。

于 2009-11-18T07:18:10.390 に答える
1

メッセージごとにさらに数バイトを追加しても問題がない場合は、ソースで完全なタイムスタンプ（64ビット）を使用してメッセージにスタンプを付け、ホップごとにエントリ/リーブのタイムスタンプデルタ（スタンプごとに1バイト）を追加することをお勧めします。双方向フローを分析することで、ボックス間のクロックスキューを把握し、検討または監視ツールへの公開のために、完全なリアルタイムのレイテンシ情報を取得できます。

于 2010-05-10T15:19:52.090 に答える
0

これを行う際の問題は、空間で「速度」を測定することとほとんど同じです。何に対してレイテンシーを尋ねなければなりませんか? 回線上で測定しようとすると、スイッチングまたは受信側のプロトコル スタックでの余分な遅延を見逃すことになります。コンピューターには2つの異なるクロックがあり、小さなエラーを導入せずに調整することはほとんど不可能であるため、エンドツーエンドで実際に測定することはできません（そして、それらは互いにドリフトします！）

本当に希望がある唯一のアプローチは、受信を確認するメッセージが一方の端から戻ってくると仮定して、往復の待ち時間を測定することです。UDP はスタックに ACK を持たないため、アプリケーションのどこかにコーディングする必要があります。x86 の高解像度タイマーのようなものを使用して、メッセージが送信されてからその応答が表示されるまでの時間を測定します。

于 2009-08-05T21:59:07.170 に答える