USB 3.0 : xHCI, BOT, UASP, Windows 7 et 8... pas si simple !

Avant de commencer cet article, nous pensions qu'il allait nous permettre de montrer l'intérêt des technologies comme le xHCI qui permettent de développer, de manière unique pour les systèmes d'exploitation, des pilotes standards et fonctionnels avec tout le matériel.

La genèse compliquée de l'USB 3.0 et surtout de ses spécifications annexes comme le xHCI et l'UASP à fait que l'on a eu un départ en plusieurs temps, qui nous vaut aujourd'hui dans nos cartes mères des contrôleurs assez inégaux sur le plan des caractéristiques.

Quelque chose qui se retrouve aussi dans les boitiers USB 3.0. Il est assez difficile de trouver sur le marché des boitiers qui soient "compatibles UASP" ! Et en trouver un qui utilise le bon modèle de contrôleur ne suffit pas forcément (la preuve avec notre boitier Thermaltake qui, lorsqu'il marchait, nécéssitait un firmware qui n'est plus disponible). Sur ce point, le retard à l'allumage des différents standards, et particulièrement d'Intel sur le xHCI doit être pointé du doigt pour sa responsabilité dans l'étât de l'écosystème USB 3.0.


Le fait que Microsoft avait annoncé que Windows 8 gèrerait nativement ces contrôleurs, et supporterait même l'UASP nous laissait penser que l'on aurait, au minimum, un progrès par rapport aux pilotes développées par les sociétés qui fabriquent les contrôleurs. S'il est vrai qu'elles connaissent bien leur matériel, elles ne font que rarement les efforts nécessaires pour tirer le maximum de performances. Pour preuve, aucun d'entre eux n'avait saisi la perche tendue par Microsoft pour proposer un pilote UASP avec leurs pilotes xHCI pour Windows 7 !

En pratique nos résultats sont tout de même une déception. S'il y a un peu de positif, on notera tout de même un bond en avant sur les transferts de gros fichiers quand l'UASP est actif par rapport a l'implémentation BOT de base sous Windows 7 (qui était elle-même bridée par sa limite de blocs de 64k), cela n'est pas forcément suffisant. Si l'on prend l'exemple du contrôleur Intel, un "simple" mode Turbo sous Windows 7 fera mieux que l'implémentation UASP de Windows 8 en termes de débits séquentiels pures.

Et du côté des transferts de petits fichiers, l'implémentation native de Windows 8 sera systématiquement plus lente que les diverses implémentations des constructeurs sous Windows 7, ce qui est tout de même un comble.


Difficile de pointer un problème particulier même s'il semble que le pilote xHCI de Microsoft semble avoir été très peu optimisé pour maximiser le nombre d'I/O, ce qui se ressent directement sur les transferts de petits fichiers. En prime, là où avec un pilote tiers comme celui développé par MCCI on obtient des gains de performances nets quand l'on augmente le Queue Depth, il ne se passe quasiment rien sur les contrôleurs qui utilisent le pilote UASP de Microsoft, nous laissant penser là aussi que le NCQ est probablement inactif, ou mal utilisé par le pilote de Microsoft. Un problème qui, on le suppose, serait peut être lié à une incompatibilité entre le pilote Windows 8 et le contrôleur utilisé dans notre périphérique ou son firmware, ce qui ne facilite pas la question. Pour rappel une fois de plus, le NCQ est actif lorsque l'on utilise un pilote non développé par Microsoft !

Bien entendu, dans la plupart des cas le niveau de performances, même s'il est plus faible sera suffisant pour la majorité des utilisateurs mais l'on ne peut que regretter que Microsoft n'ait pas tenté d'optimiser un peu plus ses pilotes USB 3.0 qui semblaient attendus par tous comme la solution à tous les problèmes. Peut être pour le prochain service pack…