Routingを支えるメカニズムそのものは前回までで説明した通りだが、今度は「では何をどのようにRoutingするか」という話を次に説明する。といっても、基本的にはHubが入ることで余分なレイテンシが入る(Store&Forwardを使う限り、これは宿命である)以上、不必要にレイテンシを増やすべきではなく、このためDPPやDPHに関してはUpstream/Downstream共に余分なSpaceを入れる事は許されていない(Photo01)。ではどういうタイミングでSpaceを入れる事が許されているかといえば、ひとつはSSCを使う場合のタイミング調整である。SCCを使う場合、どうしてもClock信号のずれが発生する。Specificationでは、SSCに起因する偏差を最小4000ppm、最大5000ppm(変調レートは30～33KHzであり、これに対しての偏差である)と規定されている。基本的にはSSCは必須項目ではなく、またSSCのプロファイルはベンダー任せとなっているあたりで、実際に利用されるケースがどの位あるかは不明だが、一応これが使われる場合、微妙にタイミングのずれが起きることはありえる。その場合にはSpaceを入れて調整することが許されている。

Photo01: SSCはSpread Spectrum Clockingの略。Clock信号は定期的なものなので、ノイズ源になりやすい。そこでClock信号が他に干渉するような場合、この影響を緩和する目的でスペクトル拡散を利用することが出来る(これはUSB 3.0のみならず、PCI Expressなどでも採用されている)。

もう一つのケースは、"Will naturally happen with protocol"というケース。Specificationでは、例えばHubがDownstream PortからHeader Packetを受け取っている最中に、Upstream PortからもHeader Packetを受け取り、これのRoutingを行わなければならないなんてケースを例に挙げている。Upstream/Downstream共に単にRoutingで済む処理であれば、これはそれほど難しくはなく、両方を独立に処理すれば済む話である。が、例えばDownstreamからのHeader PacketがHubに対してのRequestだったりすると、場合によってはUpstream PortからのHeader PacketをDownstream Portに転送する前に、Downstream PortからのHeader Packetの返答を返してやる必要があるかもしれない。こうなると、Upstream Portから見れば余分なSpacingに見えることになる。

ちなみにこうしたSpacing(というか、Delay)の最大値はtPropagationDelayJitterLimitとして定められており、8ns以内ということになっている。この制約は、ITP(Isochronous Timestamp Packet)への影響を最小限にしたいためという事のようだ。ITPはこちらで触れたとおり、Isochronous TransferのBoundaryとして利用されており、なのでこれがあんまり遅れてしまうと全体への影響が非常に大きいからということだろう。ITP自身が、Bus interval boundaryからの時間差をtIsochTimestampGranularityで規定しており、これが16.67nsなので、この半分以下に抑えろ、ということだろう。

また、これに絡んでもう一つあるのがPacket Insertionである。今の例の場合、例えばHostは連続してPacket HeaderやPacket Payloadを送出しており、これがUpstream Portから受信され、特定のDownstream PortにRoutingしてゆくわけだが、それと並行してそのDownstream PortからPacket Headerを受け取る形になる。勿論殆どの場合はHostに対する応答であって、なのでHubはそのままそれをUpstream PortにRoutingして送り出せば済むのだが、希にHubに対するPacketが混じることは当然あり、その場合HubはHostからのPacketに混ぜる形で自身の応答を送り返さねばならない。この自身の応答を、どう挿入(Insertion)するかという問題である。これに関して、まずDonwstream Port側(と書くと判りにくいので、Upstream Port→Downstream Portのフロー)に関してはITPを最重要と捉えており、これへの影響を最小にすることが求められている。つまりHubはITPに関係するPacketに(事実上)割り込んではいけないという形になる。それ以外については、「Upstream Portで受け取った順にDownstream Portに送出せよ」としており、この順序を崩さなければ任意のタイミングで必要なPacketを混ぜる事が可能となっている。

逆にDownstream Port→Upstream Portに関しては、Link Commandがまず最優先で、次がHeader、最後がDataとなっており、この順でHubによるInsertion(現実的には、上位Hubに対するリクエストとかHostに対するResponseを返す)という事になるだろう。ちなみにSpecificationによれば、同じDownstream Portから送られてきたPacketは、そのままの順でUpstream Portに送り出すべしと規定はされているが、複数のDownstream Portで同時受信の場合の規定は特に見当たらない。まぁ実際には各Portに届いた順にRoutingされていくので、そこまで規定する必要はないのかもしれないが。

(続く)