次に、ProtoclレベルでのTransactionの実際である。こちらは4月の方でしか説明がないが、8月のプレゼンテーションでは特にこれを打ち消すような話はなかったから、おそらくこのままであろう(Photo29)。

Photo29: 全ての転送はHostからの指示で行うという構造は従来と変わらず。ただ転送速度が上がったためか、Defer Requestという項目が追加されたのは目新しい。もっともこの場合、単にDelayして再Requestではなく、そのRequestを破棄して改めてRequestを出すというインプリメントはちょっと豪快。

実際の転送であるが、USB 2.0は1本の信号線で送受信を行う関係で、最初にトークンの受け渡しが入り、転送方向が決まった後でデータの転送、最後にWrap upのHandshakeが入っていた(Photo30)。対してUSB 3.0の場合。まずDevice→Hostの転送の場合(Photo31)、最初にHost→Deviceでコマンドが発行され、これを受けたデバイスは直ちにデータ転送を開始する。この2つのパケットは異なる信号線で行われるから、最後のHandshakeが不要になるというわけだ。一方Host→Deviceの転送の場合(Photo32)は、いきなりHostから転送を掛けてしまえばよく、それが終わったらDevice→Hostに受信終了のAckを返すだけとなる。つまり2stepのHandshakeになるわけで、平均的なTurn around Timeはやや短くなることが期待される。

Photo30: これに加えて、Token/Data、Data/Handshakeの間には一定のWait時間が必要となっている。これらを全部込みにして、平均的な1回の転送時間が350ns未満ということになる。

Photo31: 流石にHostがRequestを出した直後にDeviceが通信というのは難しい(それを解釈して実際に転送を開始するまで時間がかかる)から、いくばくのDelayは必要になるのは間違いない。

Photo32: 理屈は判るが、この場合Deviceは何時Hostからいきなりパケットが送られてきてもいい様に準備しておく必要があるわけで、このあたりのインプリメントがちょっと大変そうだ。いやまぁ常時大きめの受信バッファを用意しておくだけで済むのかもしれないが。

一方Isochronousについては、これはUSB 2.0と同じ125μsecとされた。ただし、実現方法がちょっと変わっているのには注意が必要だ(Photo33)。

Photo33: USB 2.0の場合、IsochronousでSynchronous Transferを掛ける場合、USBのFrame/Microframeの先頭にあるSOF(Start-of-Frame)を使ってタイミングを調整していた。ところがUSB 3.0ではそもそもSOFが無いので、Data PacketのヘッダにあるTimestampを使う事になる。これでも200ns程度の誤差で実装できる事になっている、というのが説明だが、実際はどうなのだろう?