他に、Frameworkにも一部変更がある(Photo34)ほか、Statusなどが拡張されることも示された(Photo35)。

Photo34: ぱっと見、USB 3.0 Device Capabilityはまぁ理解しやすいが、その他に関しては最終的にSpecificationが出てこないと、何がどうなっているかがさっぱり判らない。ただ、USB 2.0→3.0で、思いのほか変更が多いのは理解できる。

Photo35: bmRequestTypeが00000000BならCLEAR_FEATURE/SET_FEATUREだが、10000000BだとGET_STATUS/GET_DESCRIPTORになってしまうので、ちょっと例が違う気がするといった突っ込みはまぁいいとして、CLEAR_FEATURE/SET_FEATUREは標準で0(ENDPOINT_HALT)/1(DEVICE_REMOTE_WAKEUP)/2(TEST_MODE)といったものが用意されている。ここにU1_ENABLE～TEST MODESまでの4つが追加されるという話。これはあくまでExampleなので、実際には多岐に渡る追加/変更があるだろうと思われる。

最後にPower Managementである。USB 3.0に関してはポーリングやブロードキャストを全廃すると共に、U0～U3のモードを設けて段階的に省電力化することが目標に掲げられている(Photo36)。Power Managementは全てハードウェア側で吸収するという事も理にかなっている。ちなみにこのU0～U3が、どの程度のLatencyを伴うのか? という数字はこちら(Photo37)が判りやすい。PCI Express Gen3などと違い、Link Speedを変えるというオプションはないため、通信中の消費電力は一切変わらない訳で、非通信時の待機電力をひたすら減らすという方式である。この場合の問題は、間にHubをはさんでいる状態で、先にHostが立ち上がって通信を開始した場合にどうなるか? という話である(Photo38)。で、答えは先ほどPhoto29で出てきたDeferred Requestを使うという方法。現実的ではあるが、多段階のHubを介すると猛烈にレイテンシが増えそうであり、USB 3.0ではHubを多数使うのは現実的ではないのかもしれない。

Photo36: 問題は待機状態でどうやって外部からのイベントとかIsochronous転送を漏らさないかで、ここでPing/Ping-Responceを使うとしている。これはこちらの記事で触れた「必要に応じてInterruptに相当するものをHostに送ることが出来るようになった」を実装したものであろう。

Photo37: こちらは4月のプレゼンテーション。ところで、LFPSが8月のプレゼンテーションから綺麗に消えているところを見ると、このアイディアは放棄されたのかもしれない。

Photo38: HubにPower Managementが搭載されないのは、ここでHubまでSleep Stateに入ってしまうと、最終的にDeviceがWakeupするまでの時間が長くなりすぎるからかもしれない。