私たちが得た結果は、高頻度のトレーダー、アルゴリズムのトレーダー、およびわずかな遅延でデータ処理に偏っているすべての人にとって興味深いと思われます。
測定方法：何をどのように測定したか
測定スタンドのスキームは次のようになります。
SUT（テスト対象システム）は、CEPアプライアンスまたはSolarflareを搭載したサーバーのいずれかです（テスト対象システムの特性については、以下を参照）。
CEPapplianceとSolarflareには、共通のアプリケーション領域があります-高周波およびアルゴリズム取引。 したがって、テストドライバーが市場データ（ティック）を含むパケットの最後のバイトを送信した瞬間から、トレードリクエストを含むパケットの最初のバイトを受信した瞬間までの遅延量を測定します（ドライバーレベルのMACおよびPHY遅延は同じです）テスト環境と以下の結果値から差し引かれた両方）-いわゆるティックからトレードへの遅延。 ドライバーが最後のバイトを送信した瞬間からの時間を測定することにより、物理層に応じて、データの受信/送信速度の影響を排除します。
同様に、ドライバーが最初のバイトを送信してから測定されたシステムから最初のバイトを受信するまで、別の方法で遅延を測定できます。 このような遅延はより長くなり、次の式に従って測定値に基づいて計算できます。
レイテンシー1-1 =レイテンシーN-1 + 6.4 * int（（N + 7）/ 8） 、
ここで、 レイテンシN-1は、ドライバーが最後のバイトを送信した瞬間から最初のバイトを受信する瞬間までに測定された遅延であり、 Nはバイト単位のイーサネットフレームの長さ、 int（x）は実数の小数部分を破棄する整数への変換です。
ここに処理ダイアグラムがありますが、そのランタイムは私たちにとって関心のある遅延です：
テスト段階は何ですか？
準備：
- 入力データ-モスクワ証券取引所のACTS取引システムからの注文フローの記録されたダンプで、FASTプロトコルに従ってパックされ、UDPで送信されたメッセージの形式
- データは、ユーティリティを使用してテストドライバーのメモリにロードされます。
テスト：
- テストドライバー
- 記録されたUDPパケットを送信します（ダンプを失います）市場データ-交換によって受け入れられた購入または販売の注文に関する情報。 情報には、アプリケーションでのアクションが含まれます-新しいアプリケーションの追加、以前に追加されたアプリケーションの変更または削除、取引された金融商品の識別子、購入/販売価格、ロット数など。
- 1つのパッケージには、1つまたは複数のアプリケーションに関する情報が含まれる場合があります（2017年3月に取引所によってリリースされたデータのパッキングに関する規則の変更後、128のアプリケーションに関する情報を含むパッケージに出会いました！）;
- T1パケットが送信された時刻を記憶します。
- テスト中のシステム
- アプリケーションに関する情報を含むパッケージを受け入れます。
- 取引所によって指定されたパッケージングルールに従ってそれを開梱します（モスクワ取引所の通貨市場からの注文フローのメッセージX-OLR-CURR ）。
- 受信したパッケージのすべてのデータを使用して、内部アプリケーションブック（「ガラス」）を更新します。
- 書籍の最高（最低）販売価格が変更された場合、FIXプロトコルを介してこの価格で購入リクエストを送信します。
- テストドライバー
- アプリケーションでTCPパケットを受信します。
- T2の受信時間を修正します。
- 遅延（T2 -T1）を計算し、記憶します。
- テストは、市場データを含む90,000パケットのセットで実行され、取得された遅延値のセットで、統計値（平均、分散、パーセンタイル）が計算されます。 パケットは厳密に順番に送信されます。 パケットを送信した後、応答またはタイムアウトの期限切れを待機しています（アルゴリズムが市場データでこのパケットに応答しない場合）。 その後、次のパッケージなどを送信します。
テスト結果の処理：
- 取得した平均遅延値は、テストドライバーのメモリからアンロードされます。
- 各遅延値は、測定対象の入力パケットサイズの値とともに保存されます。
Solarflareのスタンド
SUTは、Asus P9X79 WSマザーボード、Intel Core i7-3930K CPU @ 3.20GHz、およびTCPDirectをサポートするSFN8522-R2 Flareon Ultra 8000シリーズ10Gアダプターネットワークカードを搭載したサーバーです。
このスタンド用に作成されたCプログラムは、Solarflare TCPDirect APIを介してUDPパケットを受信し、それらを解析し、アプリケーションブックを作成し、FIXプロトコルを使用して購入メッセージを生成および送信します。
メッセージを解析し、アプリケーションでメッセージを形成するガラスを作成することは、バリエーションやチェックをサポートせずに「ハード」にコード化され、最小限の遅延を保証します。 コードはGitHubで入手できます 。
ハードウェアCEPアプライアンスの略
SEPは、CEPアプライアンス、または「ハードウェアの一部」として機能します。これは、PCIeサーバースロットに挿入されたアルテラStratix V FPGAチップを搭載したDE5-Netボードであり、電力を供給されます。 10Gイーサネット接続を介したボードとの管理およびデータ交換。
FPGAチップのファームウェアには、ここで説明するテストシナリオの実装に必要なすべてを含む、多くの異なるコンポーネントが含まれていると既に述べました。
CEPapplianceのスクリプトプログラムは2つのファイルに含まれています。 1つのファイルには、データ処理ロジックプログラムがあり、これを回路と呼びます。 別のファイルでは 、回路（またはそれを実行するハードウェア）が外部の世界とやり取りするためのアダプターの説明。 とても簡単！
CEPapplianceでは、2つのバージョンの回路を実装し、各バージョンで測定を行いました。 1つのバージョン（CEPappliance ALU）では、ロジックは高レベルの組み込み言語で実装されています（行47〜67を参照）。 別の（CEPappliance WIRE）-Verilogで（行47-54を参照）。
結果
ナノ秒単位で測定されたティックからトレードまでの遅延：
| SUT | 分 | 平均 | 最大 | stddev | 95％ | 97％ | 99％ | 99.9％ |
|---|---|---|---|---|---|---|---|---|
| Solarflare TCPDirect | 1411 | 1637 | 2638 | 150 | 2022 | 2116 | 2303 | 2619 |
| Cepappliance alu | 1050 | 1125 | 1620 | 45 | 1251 | 1320 | 1415 | 1549 |
| 家電線 | 561 | 640 | 1163 | 45 | 768 | 825 | 907 | 1087 |
結論
奇跡は起こらず、FPGAに基づいて実装されたハードウェアは、Solarflare TCPDirectを搭載したサーバーに基づくソリューションよりも高速であることが判明しました。 パーセンタイルが高いほど、速度の差が大きくなります。 同時に、CEPapplianceでのソリューションの速度の変動ははるかに小さくなります。
データ処理ロジックがVerilogに実装されている場合、CEPapplianceのオプションは、組み込みのCEPappliance言語に同じアルゴリズムを実装するよりも60〜70％高速です。
ソースコード
GitHubで公開されているテストに参加したほとんどすべてのソースコードをこのリポジトリに投稿しました。
収益化の可能性があるため、テストドライバコードのみが閉じられたままになりました。 結局のところ、システムの反応速度を非常に正確に測定することができます。 この情報がなければ、高品質のHFTソリューションを作成することはほとんど不可能です。
次は？
モスクワ取引所で取引する場合など、さまざまな決定の遅延の明らかな違いが重要かどうかを調べることは論理的です。 それについては、次の記事で説明します。 しかし、先を見据えて、0.5マイクロ秒でも問題だとしましょう！