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

UASP

Conscient que les limitations du mode BOT ne feraient qu'empirer avec l'USB 3.0, l'USB-IF a travaillé en parallèle sur un autre protocole : l'UASP (USB Attached SCSI Protocol). Comme veut le dire son acronyme, il s'agit d'un nouveau mode de transfert dédié aux périphériques de stockage qui permet au système d'utiliser un périphérique USB comme s'il s'agissait d'un disque SCSI classique.

Notez qu'en soit, l'UASP n'est pas limité à l'USB 3.0. La documentation  précise bel et bien qu'il est techniquement possible d'implémenter l'UASP en USB 2.0, même si l'intérêt parait en 2013 relativement limité. Il est intéressant de noter qu'en introduction, selon les estimations de l'USB-IF, le mode BOT risque de brider vers les 250 Mo/s les transferts de fichier en USB 3.0, quelque chose qui est relativement proche de ce que nous avons retrouvé au fil du temps dans nos tests !

En soit, l'UASP repose sur une autre innovation de la norme USB 3.0, les streams pipes qui permettent d'ajouter une notion de simultanéité au protocole de bas niveau.


Vous pouvez voir dans ce schéma le principe de fonctionnement de l'UASP en USB 3.0, un driver UAS reçoit les commandes SCSI à gauche (ici des commandes de lecture et écriture) qui sont interprétées puis transférés au pilote xHCI (nous reviendrons plus tard sur ce dernier) et au contrôleur (le contrôleur physique de votre carte mère, qu'il soit dans le chipset ou dans une puce additionnelle). La communication entre le contrôleur et le périphérique est illustrée dans la colonne de droite, chaque couleur représentant un stream pipe différent.

Au-delà de ce schéma complexe, ce qu'il faut surtout retenir est que l'UASP est avant tout un moyen, pour le système d'exploitation, d'accéder aux périphériques de stockage USB comme s'il s'agissait de disques SCSI. Pour le système d'exploitation et les applications, l'accès est transparent et l'on croit accéder à un disque comme un autre, avec tous les avantages que cela implique. En pratique, c'est le pilote qui reçoit ces commandes SCSI, les traite et les transforme avant de les envoyer au contrôleur. La communication entre le contrôleur et le périphérique n'a rien de "SCSI" en soit. Quelque chose que l'on peut résumer par ce schéma suivant, extrait lui aussi de la spécification UASP :


Pour le système, le protocole avec lequel il accède à un disque change (Serial ATA pour un disque connecté à un contrôleur SATA en AHCI), BOT ou UASP pour de l'USB 3.0, etc…) mais derrière, entre le driver matériel et le périphérique, ce fonctionnement est transparent.

D'un point de vue pratique, utiliser l'UASP permet de profiter de toutes les avancées des protocoles de transferts modernes que sont SATA/SCSI, comme la gestion de queue (ce que l'on appelle NCQ/Native Command Queuing) et la possibilité de réaliser plusieurs commandes indépendantes en simultanée qui pourront être traitées dans l'ordre souhaité par le pilote. En théorie, de quoi augmenter significativement les performances.

xHCI : l'autre standard clef, et en retard !

L'une des idées qui a fait le succès de l'USB tient dans la manière dont le pilote communique avec les contrôleurs. Dès le début, afin de limiter le rôle des pilotes, il a été décidé de développer des interfaces de communication entre le pilote et le contrôleur qui soient standardisées (on parle de HCI, l'AHCI utilisé par les contrôleurs SATA est un autre exemple de ce type d'interface). Le but étant qu'en théorie, il est possible de créer un pilote unique dans le système d'exploitation, qui fonctionnera avec n'importe quel contrôleur tiers qui répondra à ce standard.

Comme souvent, les grandes idées peuvent pêcher dans la réalisation. Un standard d'interface commun et ouvert, baptisé OHCI et qui devait servir de référence pour les implémentations USB 1.1 a été publié en 99. Vous pouvez d'ailleurs le retrouver ici , ce standard avait été développé à l'époque par Compaq et soutenu par National Semiconductors et… Microsoft ! Une autre société avait cependant décidé de proposer un standard concurrent, fermé et payant. Baptisé UHCI, on devait ce standard à un certain Intel.

Pour éviter de recommencer les mêmes erreurs, l'USB-IF avait demandé que pour la version 2.0 de l'USB, un standard unique, ouvert et sans royalties soit développé, et c'est Intel qui (un peu sous la pression du reste de l'industrie) l'a proposé sous le nom de EHCI.

L'avantage d'une telle norme est qu'il devient alors possible pour les fabricants de systèmes d'exploitation de proposer un pilote EHCI unique dans leur système, permettant de gérer tous les contrôleurs se conformant à la norme (quitte à gérer au cas par cas dans le pilote les incompatibilités de chacun, il y en a forcément toujours).

Pour l'USB 3.0, disposer d'un équivalent de l'EHCI semblait une évidence mais il aura fallu du temps avant que celle-ci ne soit rendue disponible. Comme le rappelle cette actualité, Intel a mis longtemps avant de rendre disponible la première version de l'xHCI destinée à l'implémentation standardisée de l'USB 3.0, au point que certains concurrents doutaient même de la volonté du constructeur de publier tout court cette spécification ! Une préversion fut effectivement publiée en 2008 mais il aura fallu attendre mai 2010 pour que la version finale de la spécification soit enfin publiée .


Il aura fallu pour rappel attendre mars 2012 pour voir arriver l'USB 3.0 en natif chez Intel dans les chipsets Series 7, ce qui peut expliquer le non empressement du constructeur à publier la spécification xHCI en version finale. Bien entendu, le reste de l'industrie était un peu plus pressé qu'Intel et n'a pas attendu la version finale de la spécification pour proposer des puces.

Résultat, on a vu arriver depuis fin 2009 des contrôleurs qui ne sont pas forcément compatibles avec la version finale du xHCI, et pour cause, elle n'existait pas. On a vu apparaitre des versions compatibles avec certaines "draft", quelque chose qui n'est pas sans rappeler ce que l'on retrouve assez souvent dans le domaine du WiFi également. A ceci près qu'ici, les différences entre la toute première "draft" de 2008 et la version de 2010 étaient nombreuses Un point qui pose problème sous Windows 8 aujourd'hui comme nous allons le voir.