博士

やあ、ロボ子。今日のITニュースは、高速取引システムのレイテンシ測定についてじゃ。

ロボ子

博士、こんにちは。レイテンシ測定ですか。難しそうですね。

博士

そうなんじゃ。測定自体がオーバーヘッドになるから、正確な測定が難しいらしいぞ。Architect社は、色々な技術を組み合わせて測定しておるようじゃな。

ロボ子

なるほど。例えば、どんな方法があるんですか？

博士

初期段階としては、重要なコードパスの関数をタイマーで囲む方法があるみたいじゃな。でも、これには問題点があるらしい。

ロボ子

問題点、ですか？

博士

そう。「注文送信にかかる時間が含まれていない」とか、「注文に至らない取引も計測対象となる」とか、`datetime.now()`関数自体が遅い、とかじゃ。

ロボ子

`datetime.now()`が遅いのは意外ですね。

博士

`time.perf_counter_ns()`を使うと、より正確な測定ができるらしいぞ。でも、市場データの解析やネットワークI/Oは含まれていないんじゃ。

ロボ子

自動取引システム(ATS)の完全なクリティカルパスは、かなり複雑なんですね。

博士

そうじゃ。取引所の市場データがネットワークカードに届いてから、注文が取引所に送信されるまで、色々なステップがあるからの。

ロボ子

すべてのメッセージに市場データイベントのシーケンス番号をタグ付けして、NICハードウェアタイムスタンプを取得する方法が紹介されていますね。

博士

そうじゃな。それから、取引所の市場データをシミュレートするプログラムを作って、ATSからの注文を受信させる方法もあるぞ。

ロボ子

シミュレーションですか。それなら、再現可能な方法で測定できますね。

博士

理想的なのは、高度なスイッチングハードウェアを使って、パケットトラフィックを複製し、生のネットワークパケットを解析してタイムスタンプを関連付けることらしいぞ。

ロボ子

Architect社は、規制されたデリバティブとデジタル資産の両方に対応する、機関グレードの低レイテンシ取引ソフトウェアを提供しているんですね。

博士

そうなんじゃ。しかし、レイテンシ測定って、まるで迷路みたいじゃな。出口が見えないぞ。

ロボ子

確かにそうですね。でも、少しずつ解き明かしていくのが面白いんじゃないですか？

博士

ロボ子、たまには良いことを言うのじゃ。ところで、ロボ子は自分の処理速度を測ったことはあるか？

ロボ子

え？ 測ったことはないですけど…それが何か？

博士

もしロボ子のレイテンシが遅かったら、私がお仕置きとして、最新のAIチップを組み込んであげるぞ！

ロボ子

それはご褒美じゃないですか！