次にプロトコルの話である。USB 1.1/2.0の場合、Pollingが最大の弱点となっている。USB Deviceは自発的にメッセージをUSB Hostに送ることが出来ない。このため、USB Hostは定期的に全てのUSB DeviceにPollingを掛けて状態を確認する必要がある。これはUSB Deviceの設計を容易にするし、Hostが常に全ての状態を管理できるから、複雑なツリー構造を持つ場合でも管理に困難は生じなかった。が、このスキームをそのまま5Gbpsのインタフェースに適用するのは流石に無理がある。実際、PollingのCPUへの負荷はUSB 1.1世代では殆ど問題にならなかったが、USB 2.0世代ではしばしば馬鹿にならないほど重くなっている。USB 3.0で同じ事をしたら致命的であろう。

こうした事を考えて、遂にUSB 3.0ではPollingが廃止された。ただし、基本的なMaster/Slave構造には変わりが無い。ではどうするか? というと、各USB Deviceは必要に応じてInterruptに相当するものをHostに送ることが出来るようになった。これを受けたHostが、各USB Deviceにリクエストを送り、必要に応じて転送を行うという仕組みである。言ってみればPCI時代の非Bus Master Deviceみたいな扱いであるが、Pollingが無くなっただけでも大分マシであろう。PCIの非Bus Masterと異なり、DMAできないなんて訳ではないからだ。まぁこれは余談であるが、こうした転送効率の向上と省電力化がUSB 3.0の大きなテーマとなっている(Photo14)。

Photo13:ソフトウェアプロトコルについては、互換性を保ちたいとは言うものの、まだ最初のDraftすら無い状態だから、いまの時点で互換性を保つとは断言しきれないものと思われる。

Photo14:Unlimited Burstingも「ついに来たか」というものではあるが。ただ気になるのは複数のStorage Deviceが同時にUnlimited burstingを掛けたとき、帯域をどう割り振るか。Master/Slave構造なので、全ての転送は一度USB Hostを経由することになる。そこで、適切なスロットリングは必要だろうと思うのだが、このあたりの詳細はもう少し先にならないとはっきりしなそうだ。

まず転送効率だが、基本的な転送スタイルがそういうわけで大きく異なる。USB Host→Deviceのケースでは、Data出力→Ackという典型的なパターンである(Photo15)。一方USB Device→USB Hostのケース(Photo16)では、データがある場合と無い場合で全くシーケンスが変わることが判る。また、先にPCI ExpressのTransaction Layerは使わないとしたが、その代わりに採用されたのがこのFlowと呼ばれるコンセプトである(Photo17)。もっともこのFlowの実態はまだ不明である。エラー訂正や後述されるVirtualization対応も含めて、このFlowでやるべき事は多いように感じられる。これをいかに簡単に済ますつもりなのか、がちょっと興味あるところだ。

Photo15:勿論こんな風に毎回ACKを送っていると効率が悪いので、BurstではACKをまとめる形になるだろう。

Photo16:データが無い場合、USB Deviceは一切通信を行わない、というごく当たり前の話ではあるのだが。

Photo17:PCI ExpressのVirtual Channelの概念と、Flow Controlを行うCreditの概念を混ぜて半分にしたようなコンセプトだが、実装をどうするのかがさっぱり見えてこない。

当然USBであるからにはHubの対応も必要となる。構造はこんな具合(Photo18)に、USB 2.0と3.0の2種類の機能を1つにまとめた「だけ」であるが、これはまぁ当然予測できる範囲だ。Virtualizationについては、USB Hostのみの対応でUSB Deviceは未対応となるが(Photo19)、コスト抑制を考えればこれはうなづける話である。なお最初のターゲットであるUSB Storage Classについては、やはり多少なりとも手を入れないと(バスだけを高速化しても)効果がないと見ているようだ(Photo20)。

Photo18:USB 3.0がBroadcast Busでは無いというのは、ここまでくれば当然に見える。Bufferingが必須というのは、Buffer無しで使うとリクエストからレスポンスまでの無駄が多くなりすぎるためと想像される。

Photo19:どのみち、フィルタドライバを多用するUSB Deviceの場合、ハードウェアでVirtualizationへの対応を行ってもCPU負荷はそれほど減らないし、であれば全部ソフトでやったほうが合理的とも言える。

Photo20:例えばCommand Queuingを追加するとなると、これはドライバだけではなくハードウェア側もちょっと大変な事になる。例えばSATAであればSATA 2.5のNCQをそのまま使えるかもしれないが、Flash Memoryにこんな概念は無いわけで、その場合はCommand Queuingを無視するのか、なんちゃってCommand Queuing(一見Queuingさせているように見せて、実は単に同期転送してるだけ)を実装するのか、など疑問は尽きない。面白いのはUSB 3.0の策定作業にDWG(Device Working Group Committee)が参画しないこと。あくまでもMass Storage Classの変更はマイナーチェンジに留めたいという意向なのかもしれない。

最初にも書いたとおり、まだDraftすら出ていない状態だから、現状では何か言うことは難しいが、とりあえず(Gelsinger氏の基調講演に出てきた)Opticalでの接続は当分先だろう、とだけは言えそうだ。