Interruptが終わったので、次はIsochronous Transferであるが、その前にHost Timing Informationについて説明しておく。USB 2.0までは、SoF(Start of Frame)がHost Controllerから全てのDeviceに対してbroadcastされていた。このSoFはUSB 1.1なら1.00ms±0.0005ms、USB 2.0ならば125μs±0.0625μs間隔で常に送出されていたから、DeviceはこのSoFを受信したタイミングに合わせて動作を行えばよかった。ところがUSB 3.0ではSoFは実際にHostと通信を行うDeviceにしか渡されないため、従来SoFでタイミングを合わせていたDeviceは、毎フレーム通信を行わないとタイミングが取れなくなるという問題が発生した。

勿論、例えばDevice側で独自に時間を合わせるといった方法はあるし、あるいは時間あわせをDPを使って行う(それこそIsochronous Transferを使い、HostからTimestampなり何なりを定期的に送る)方法はあるのだろうが、前者についてはHost側の時計が狂っていると齟齬が発生してしまうし、後者については無駄にUSBの使用率を上げることになる(これはそのまま省電力性を損なうことになるし、Deviceの数が多くなると転送効率が落ちることになる)し、Host側のDriverあるいはApplicationに手を入れる必要もでてくる。Host側CPU負荷も上がることになるだろう。何より、USB 1.1/2.0との下方互換性を保つというUSB 3.0の当初の目的に反する事になる。

そこで互換性維持のために設けられたのがIsochronous Timestamp Packet(ITP)である。Hostは、U0となっている全てのDownlink Portに対して定期的にITPを送出し、またHubはITPを受け取ったらそれを配下のActive(U0)になっている全てのDownlink Portに転送を掛けることになっている。BroadcastというメカニズムそのものはUSB 3.0には無いが、事実上のBroadcastをこうした形でインプリメントするわけだ。ちなみにこれは、あくまでもTimestampが必要なDevice(というか、Endpoint)のみが使えばいい話で、こうしたTimestampが不要なDevice/Endpointの場合、ITPには何も送り返す必要はなく、単にITPを破棄すれば良いことになっている。またIsochronous TransferをサポートしていないDeviceも、同様にITPは無視して良いとされている。

そのITPであるが、こんな形で利用される(Photo01)。Bus Intervalは以前も出てきたが、125×2^n(n:0～15)μsと定められており、最小では125μs、最大では4096msという間隔になっている。このBus Intervalが開始される最初のタイミングで、まずITPが送出され、後はDeviceの要求に応じてIsochronous INなりIsochronous OUTなりの転送が順次行われるという仕組みだ。ちなみにPhoto01の図では、Isochronous INのDevice(上半分)とIsochronous OUTのDevice(下半分)の2つのDeviceが同時に転送を行っている構図である。どちらの場合でも、まずHost→DeviceにITPが送信され、その後でまずはIsochronous INのHandhsakeが始まる。HandshakeはまずHost→DeviceにACK TPが送られ、次いでDPがDevice→Hostに送られる。このDPの転送中に、Isochronous OutのHandshakeが始まる形だ。USB 3.0の場合は全二重の通信が可能だから、こんな具合にオーバーラップが可能という良い例である。

Photo01: Universal Serial Bus 3.0 SpecificationのFigure 8-45から抜粋

さて、それではIsochronous Transferである。Photo01にも示したとおり、Isochronous TransferはBus Interval毎に必ず転送を行う「権利がある」転送方式である。あくまでも権利であって、実際には転送しない事も勿論可能である。例えばUSBマウスなりUSB Keyboardの場合、全くキータッチやマウス操作をしなければ、「本来は」何も無駄に転送を行う必要はない。Photo01の下側を見ると、Isochronous Outが最初(Bus Interval N)と最後(Bus Interval N+3)では行われているが、途中(Bus Interval N+1/N+2)では入っていない事が示されている。あくまでそのスロットは用意されるが、必ずしもデータを送る必要は無い。

といっても、Isochronous Transferもまた、制御を行うのはHost(というか、Hostを管理しているCPU)である。だから、何らかの方法で「今はキー入力が無い」ということをCPUが事前に知る方法があれば、そのUSBキーボードからのIsochronous INのTransferを省くことが可能になるが、実際はキー入力があるか無いかをUSB経由で問い合わせしないと判らない訳で、結局Isochronous INに関しては間違いなく毎回発生する、という事になる。

(続く)