動機

480 MBit / sの信号速度で、USB 2.0デバイスは最大60 MB / sでデータを送信できるはずです。しかし、今日のデバイスは[ Wiki：USB ] を読んでいる間、30-42 MB / sに制限されているようです。これは30％のオーバーヘッドです。

USB 2.0は、10年以上にわたって外部デバイスの事実上の標準となっています。USBインターフェースの初期から最も重要なアプリケーションの1つは、ポータブルストレージです。残念ながら、USB 2.0はこれらの帯域幅を必要とするアプリケーションの速度を制限するボトルネックであり、たとえば今日のHDDは90 MB / s以上の連続読み取りが可能です。市場での長いプレゼンスとより高い帯域幅に対する絶え間ないニーズを考慮すると、USB 2.0エコシステムは長年にわたって最適化され、理論上の限界に近い読み取りパフォーマンスに達すると予想されるはずです。

この場合の理論上の最大帯域幅はどれくらいですか？すべてのプロトコルにはUSBを含むオーバーヘッドがあり、公式のUSB 2.0規格によると53.248 MB / s [ 2、表5-10]です。つまり、理論的には、今日のUSB 2.0デバイスは25％高速になる可能性があります。

分析

この問題の根本に近い場所に到達するために、次の分析では、ストレージデバイスからシーケンシャルデータを読み取り中にバス上で何が起こっているかを示します。プロトコルはレイヤーごとに分類されており、バルクアップストリームデバイスの最大理論値が53.248 MB / sである理由について特に興味があります。最後に、追加のオーバーヘッドのヒントを提供する可能性のある分析の制限について説明します。

ノート

この質問では、10進数のプレフィックスのみが使用されます。

USB 2.0ホストは、複数のデバイス（ハブ経由）およびデバイスごとに複数のエンドポイントを処理できます。エンドポイントはさまざまな転送モードで動作できます。ホストに直接接続され、高速モードでアップストリームバルクエンドポイントを介してフルパケットを継続的に送信できる単一のデバイスに分析を制限します。

フレーミング

USB高速通信は、固定フレーム構造で同期されます。各フレームの長さは125 usで、フレーム開始パケット（SOF）で始まり、フレーム終了シーケンス（EOF）によって制限されます。各パケットはSYNCで始まり、EOF（End-Of-Packet）で終わります。これらのシーケンスは、わかりやすくするために図に追加されています。EOPはサイズが異なり、パケットデータに依存します。SOFの場合、常に5バイトです。

新しいタブで画像を開くと、拡大版が表示されます。

取引

USBはマスター駆動型のプロトコルであり、各トランザクションはホストによって開始されます。SOFとEOFの間のタイムスロットは、USBトランザクションに使用できます。ただし、SOFとEOFのタイミングは非常に厳密であり、ホストは空きタイムスロット内で完全に完了できるトランザクションのみを開始します。

関心のあるトランザクションは、成功したバルクINトランザクションです。トランザクションはトッケンパケットINで始まり、ホストはデータパケットDATA0 / DATA1を待機し、ハンドシェイクパケットACKで送信を確認します。これらすべてのパケットのEOPは、パケットデータに応じて1〜8ビットです。ここでは最悪のケースを想定しました。

これら3つのパケットのそれぞれの間で、待ち時間を考慮する必要があります。これらは、ホストからのINパケットの最後のビットとデバイスのDATA0パケットの最初のビットの間、DATA0パケットの最後のビットとACKパケットの最初のビットの間にあります。ホストはACKを送信した直後に次のINの送信を開始できるため、これ以上の遅延を考慮する必要はありません。ケーブル伝送時間は最大18 nsと定義されています。

バルク転送では、INトランザクションごとに最大512バイトを送信できます。また、ホストは、フレーム区切り文字の間でできるだけ多くのトランザクションを発行しようとします。バルク転送の優先度は低くなりますが、他の保留中のトランザクションがない場合、スロットで利用可能な時間をすべて占有する可能性があります。

適切なクロックリカバリを確保するために、標準ではメソッド呼び出しビットスタッフィングを定義しています。パケットが同じ出力の非常に長いシーケンスを必要とする場合、追加のフランクが追加されます。これにより、最大6ビットの後にフランクが確保されます。最悪の場合、これにより合計パケットサイズが7/6増加します。EOPはビットスタッフィングの影響を受けません。

新しいタブで画像を開くと、拡大版が表示されます。

帯域幅の計算

バルクINトランザクションには、24バイトのオーバーヘッドと512バイトのペイロードがあります。これは合計536バイトです。間のタイムスロットは7487バイト幅です。ビットスタッフィングを必要とせずに、13.968パケットのスペースがあります。1秒あたり8000マイクロフレームであるため、13 * 512 * 8000 B / s = 53.248 MB / sでデータを読み取ることができます

完全にランダムなデータの場合、2 ** 6 = 64連続6ビットのシーケンスのいずれかでビットスタッフィングが必要であると予想されます。それは（63 * 6 + 7）/（64 * 6）の増加です。ビットスタッフィングの対象となるすべてのバイトにその数値を掛けると、合計トランザクション長は（19 + 512）*（63 * 6 + 7）/（64 * 6）+ 5 = 537.38バイトになります。その結果、マイクロフレームあたり13.932パケットになります。

これらの計算には別の特別なケースがありません。この規格では、192ビット時間の最大デバイス応答時間を定義しています[ 2、Chapter 7.1.19.2]。これは、デバイスが完全な応答時間を必要とする場合に、最後のパッケージがまだフレームに収まるかどうかを判断するときに考慮する必要があります。7439バイトのウィンドウを使用して、そのことを説明できます。ただし、結果の帯域幅は同じです。

残っているもの

• エラーの検出と回復はカバーされていません。エラーが頻繁に発生するか、エラーの回復に時間がかかり、平均的なパフォーマンスに影響を与える可能性があります。

• パケットとトランザクションの後、ホストとデバイスが即座に反応することを想定しています。私は個人的に、どちらの側のパケットまたはトランザクションの終わりに大きな処理タスクの必要性を見ていないので、ホストまたはデバイスが十分に最適化されたハードウェア実装で即座に応答できない理由を考えることができません。特に通常の操作では、ほとんどのブックキーピングとエラー検出作業はトランザクション中に実行でき、次のパケットとトランザクションはキューに入れられます。

• 他のエンドポイントへの転送または追加の通信は考慮されていません。ストレージデバイスの標準プロトコルでは、貴重なスロット時間を消費する連続的なサイドチャネル通信が必要になる場合があります。

• デバイスドライバーまたはファイルシステムレイヤーのストレージデバイスには、追加のプロトコルオーバーヘッドがある場合があります。（パケットペイロード==ストレージデータ？）

質問

• なぜ今日の実装は53 MB / sでストリーミングできないのですか？

• 今日の実装のボトルネックはどこですか？

そして潜在的なフォローアップ：なぜ誰もそのようなボトルネックを排除しようとしなかったのですか？

参照資料

[1] 公式のUSB 2.0仕様

[2] 仕様の高速PDFミラー

私の人生のある時点で、私は大企業向けのUSBビジネスを運営していました。私が覚えている最良の結果は、大容量記憶装置の320 Mbpsの実際のデータスループットをプッシュできるNEC SATAコントローラーでした。おそらく現在のsataドライブはこれ以上の能力があるでしょう。これはBOTを使用していました（一部の大容量ストレージプロトコルはUSB上で実行されます）。

技術的な詳細な回答をすることはできますが、あなたは自分自身を推測できると思います。確認する必要があるのは、これはエコシステムのプレイであり、大幅な改善を行うには、Microsoftのような人がスタックの変更、最適化などを行う必要があることです。相互運用性は速度よりもはるかに重要です。既存のスタックは多数のデバイスのミスを慎重にカバーしているため、USB2仕様が発表されたとき、おそらく初期デバイスは仕様にバグがあるため、認証システムにバグがあるなど、仕様を実際に確認しなかったためです。 LinuxまたはMS用のカスタムUSBホストドライバーと高速デバイスコントローラーを使用して自家醸造システムを構築する場合、おそらく理論上の限界に近づくことができます。

ストリーミングに関しては、ISOは非常に高速であるはずですが、アプリの95％がバルク転送を使用しているため、コントローラーはそれをあまりうまく実装していません。

ボーナスの洞察として、たとえば、今日ハブICを作りに行った場合、ドットに従ってスペックを守れば、実質的にゼロチップを販売します。市場のすべてのバグを知っていて、ハブICがそれらに耐えられることを確認すれば、おそらく市場に参入することができます。私は今日、いまだに多くの悪いソフトウェアとチップが存在することを考えるとUSBがどれだけうまく機能しているかに驚いています。

これは非常に古いトピックですが、まだ回答がありません。これは私の試みです：

なぜ今日の実装は53 MB / sでストリーミングできないのですか？

計算はほぼ問題ありませんが、フレームマーカー間の使用可能なバイト数のいくつかのことを忘れています。

1. 各マイクロフレームには、EOF1およびEOF2と呼ばれる2つのしきい値があります。EOF1の時点以降にバスのアクティブ性が発生してはなりません。このポイントの配置は複雑ですが、通常の位置は次のSOFの前に560ビット時間です。ホストは、チャネルからの応答がこのしきい値に達しないようにトランザクションをスケジュールする必要があります。計算された7487バイトのうち約70バイトを消費します。

2. 「ランダムデータ」を想定しています。これはまったく根拠がなく、データは何でもかまいません。したがって、ホストは、最大ビットスタッフィングオーバーヘッド512 * 7/6 =〜600バイトで、最悪の場合のペイロードのトランザクションをスケジュールする必要があります。当然のことながら、24バイトのトランザクションオーバーヘッドが計算されます。これにより、マイクロフレームごとに（7487-70）/ 624 = 11.88トランザクションが得られます。

3. ホストは、他のアクティビティの制御トランザクション用に帯域幅の約10％を予約する必要があるため、約10.7トランザクションを取得します。

4. また、ホストコントローラーはリンクリストを管理する際に一定の遅延があるため、トランザクション間に追加のギャップがあります。

5. デバイスはルートから5ハブ/ホップ離れている場合があり、応答遅延は最大1700 nsになる可能性があり、各トランザクションバジェットのもう106バイトを消費します。生の見積もりでは、予約された帯域幅を考慮せずに、uFrameあたり10.16トランザクションのみを作成します。

ホストはuFrame内の実際のトランザクションの到着に基づいて適応型の再スケジュールを行うことはできません。ソフトウェアの観点から禁止されるため、ドライバーは最も保守的なスケジュールを使用します。秒。これは、非常に優れたUSBペンドライブが提供できるものです。

いくつかのクレイジーな人工ベンチマークは、uFrameごとに最大11トランザクションまで処理できるため、44 MBpsになります。そして、これはHS USBプロトコルの絶対最大値です。

今日の実装のボトルネックはどこですか？

上記からわかるように、問題はありません。すべての生のビット時間スペースは、プロトコルのオーバーヘッドによって消費されます。