最短レイテンシイーサネット：バイト指向のNIC？

Question

これは、ネットワークエンジニアリング（ホストに関係するため）とサーバーフォールト（どちらかというと...実際はわかりません）の両方で保留にした質問です。私はそれがここでより意味をなさないことを望んでいます。

まず、いくつかのコンテキスト。高周波トレーダーは非常に高速なネットワーキングに依存しています。 In 2014 they were already working at the level of about 750 nanoseconds with 10Gb Ethernetと競合し、単一ナノ秒が重要であることにより、より低いレイテンシに達する。

驚くべきことは、10GbEフレームに1バイトあたり約1nsかかることです。したがって、典型的なNICがフレームの受信を開始して終了するまで、ハードウェアの残りの部分で使用できるようにするために、最小限のフレームで最低64 nsが経過しています。 1500バイトのフレームの場合、1マイクロ秒より長い時間が経過しています。だからあなたがそれに取り組む前にフルフレームを持つのを待っていれば、あなたは貴重な時間を無駄にしています。

しかし、それは私が見たすべてのイーサネットNICとまったく同じです！実際、DPDKやNetMapのようなカーネルバイパスフレームワークでもフレームの細かさが働くため、フレームレスのレイテンシに達することはありません。

イーサネットフレーム内のデータがフレーム内で14バイトから始まるとします。残りのフレームが受信されている間にそのデータの処理を開始した場合は、最低50 ns、おそらくその20倍を節約します。それはあなたが単一のnsのために戦っているときに大きな利点となるでしょう。

Iは、2つの可能性を参照

：フレームが完全に受信される前に

1. HFTs等は、処理データの潜在的な時間利得をカウントしていません。不条理に思えます。彼らはスピードを上げるためにFPGAを使用していますが、すべての待ち時間を無駄にすることは許されていますか？
2. 彼らは実際にはそのためにもDPDK規格によって

、私の質問にいくつかのかなり専門的なハードウェアを使用している：彼らはそれをどのように行うのですか？誰もが "バイト指向"のイーサネットNICを知っています。これは到着時にフレーム内の1バイトを利用できるようにしますか？そのような場合、そのようなNICはどのように動作しますか？たとえば、ユーザーにストリームを表示しますか？おそらくそれ自身のネットワークスタック/サブシステムもありますか？

---

今、私はすでにNEとSFで質問からのコメント「不可能/悪い/不浄のだという」いくつかの典型的なを収集してきたので、私は先制それらをここにお答えします：

あなたが欲しいです製品の推奨

いいえ、何かがあれば、プログラミングモデルについて説明しているか、サブフレームのレイテンシを取得する方法についてのいくつかの洞察があります。しかし、目標はこれがどのように行われるかを学ぶことです。

また、ハードウェアの推奨事項SEについても知っています。それは私が望むものではないので、私はそこに尋ねていません。

あなたは「なぜ誰かがこれをしないのですか」と尋ねています。

号には、私は、彼らはそれを行う方法を求めています伝統的なNICの信じられないほど低いレイテンシーの話があることを述べ、及び。私は、バイト指向のNICとカスタムハードウェアの2つの可能性を先取りしました。

これはまだ別のものかもしれません。例えば、それらの〜750nsを測定する方法は、フレームが（従来の）NICによって利用可能になった瞬間からです。これはすべての私の質問を欺くだろう。また、すでにナノ秒を削るためにFPGAを使用していることを考えると、これは驚くべき無駄です。

フレームが有効かどうかを確認するには、フレームの最後にFCSが必要です。

FCSは必要ですが、それを待つ必要はありません。数十年前からメインストリームのCPUで使用されていた投機的実行と分岐予測技術を見てみましょう。分岐後の一連の命令に対して投機的に開始し、分岐が取られなかった場合、処理は破棄されます。スペキュレーションが正しければレイテンシが改善されます。もしそうでなければ、CPUはとにかくアイドルだったでしょう。

イーサネットフレームでも同様の投機的手法を使用できます。フレームの先頭のデータに対してASAPを開始し、フレームが正しいことが確認されたらその作業にコミットします。

最近のイーサネットでは、むしろ衝突（スイッチはどこでも）が見つからないと予想され、BERが非常に低いと定義されています。したがって、1フレームが無効と判明した場合に備えて、すべてのフレームに1フレームのレイテンシを強制することは、ナノ秒を気にしていると明らかに無駄です。

イーサネットはバイトベースではなく、フレームベースです。バイトにアクセスする場合は、の代わりにシリアルプロトコルイーサネットを使用してください。

それが完全に受信れる前フレーム内のデータにアクセスすると、「bastardization」であれば、私はあなたにそれを破ることは残念ですが、これはCut-through switchingで1989年以来、少なくとも続いています。実際、私が記述した技術は不良フレームを落とすので、不良フレームを転送するカットスルースイッチングよりもきれいです。

バイトあたりの割り込みを取得するのは恐ろしいことです。ポーリングを行う場合は、RX専用のフルCPUを使用する必要があります。 NUMAの待ち時間は不可能になります。

これらの点はすべて、DPDKなど（NetMap？など）によって既に疑われています。もちろん、システムを慎重に構成して、ハードウェアではなくハードウェアで作業していることを確認する必要があります。割込みはポーリングによって完全に回避されます。 1GHzの3GHzコアは、10GbEでフレームを落とさずにRXに十分に届きます。 NUMAは既知の問題ですが、あなたはそれを注意深く扱わなければなりません。

より高速のイーサネット標準に移行して、待ち時間を短縮することができます。

はい、100GbEは10GbEよりも高速です。しかし、あなたのプロバイダが10GbEで動作している場合や、競争が100GbEに移行している場合は、それは役に立たないでしょう。目標は、特定のイーサネット標準の待ち時間を短縮することです。