HardWare.fr


USB 3.0 : xHCI, BOT, UASP, Windows 7 et 8... pas si simple !
StockageStockage externe
Publié le Jeudi 21 Mars 2013 par Guillaume Louel

URL: /articles/889-1/usb-3-0-xhci-bot-uasp-windows-7-8-si-simple.html


Page 1 - Introduction

Lancé officiellement en novembre 2008, le standard USB 3.0 est arrivé avec une promesse simple : augmenter les débits de 480 Mbit/s pour l'USB 2.0 à 5 Gbps. En pratique, et comme nous l'avions vus en 2011, les choses sont un peu plus complexes. Les 5 Gbps théoriques reposent sur un encodage de chaque octet sur 10 bits, ce qui réduit à environ 500 Mo/s la vitesse théorique atteignable.


Extrait de la specification USB 3.0 à propos de l'efficacité

Vitesse à laquelle il faut encore soustraire les différents protocoles utilisés pour piloter l'interface en elle-même, pouvant atteindre environ 20%. En soit, cette question n'est pas nouvelle puisque même aujourd'hui, nos cartes mères peinent à dépasser les 35 Mo secondes en lecture en USB 2.0, loin du débit théorique maximal de l'interface.

Malgré tout, les marges de progression par rapport à l'USB 2.0 sont importantes mais comme nous l'avons vus au fil des années (par exemple ici, , , ou encore là), s'approcher des 400 Mo/s sur un port reste relativement rare.


Certaines cartes mères peuvent intégrer plusieurs contrôleurs USB 3.0. A gauche les deux premiers ports sont gérés par un contrôleur ASM1042, à droite par le chipset Intel.

Au fil des tests, beaucoup de raisons nous sont venues pour expliquer ces performances, certes elevées pour l'utilisation qu'un tout à chacun peut faire de ces ports, mais médiocres par rapport aux possibilités. L'absence de gestion native sous Windows 7 de l'USB 3.0 est un facteur qui revient souvent, tout comme la qualité des contrôleurs, que l'on parle de ceux de la carte mère ou de ceux intégrés dans les périphériques. Suite à l'arrivée de Windows 8, qui intègre - lui - une gestion native de l'USB 3.0, nous avons voulu revenir sur le sujet et voir si le nouvel OS de Microsoft permet à l'USB 3.0 de tenir toutes ses promesses !

Un standard complet et complexe

Pour essayer de comprendre un peu mieux, revenons un instant sur la genèse de l'USB 3.0. Le standard a été développé par un consortium d'entreprises informatiques regroupés au sein de l'USB-IF . Parmi les membres, on retrouve en tête Intel et Microsoft, accompagnés d'autres sociétés comme HP, Renasas, ST-Ericsson et Texas Instruments.


La spécification USB 3.0  écrite par les membres de l'USB-IF est un document très complet. Un peu plus de 530 pages qui définissent tout ce qui concerne le standard, du mode de fonctionnement "SuperSpeed" aux protocoles de transferts, en passant par les prises et câbles utilisés. Au-delà du fait d'augmenter les débits théoriques, la spécification introduit d'autres nouveautés. Une des limitations de l'USB 2.0 était son protocole utilisé pour communiquer avec les périphériques de stockage, appelé "Bulk-Only Transport" et souvent abrégé BOT. L'idée de ce mode est d'envoyer des blocks de commande pour initier les communications avec le périphérique, commandes qui doivent recevoir une réponse (ACK) avant de pouvoir envoyer la suivante.

Si ce mode de fonctionnement à l'avantage d'être simple à implémenter (il faut se rappeler que la première version de l'USB date de 1996 !), il n'est plus réellement au gout du jour. En effet, les transactions devant s'exécuter les unes après les autres, le protocole BOT est de facto "mono-thread". Qui plus est, les transactions sont unidirectionnelles, on peut envoyer ou recevoir, mais l'on ne peut pas effectuer les deux en même temps. Impossible également de mettre en queue plusieurs opérations pour gagner du temps. Bref, le mode BOT est singulièrement dépassé, ce qui a valu le développement en simultané d'une autre spécification…


Page 2 - D'autres standards complémentaires : UASP, xHCI


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.


Page 3 - USB 3.0 et les Windows


Windows 7 : pas de gestion native

Lancé en octobre 2009, Windows 7 intègre nativement un pilote EHCI capable de piloter les contrôleurs USB 2.0. Si sa sortie est ultérieure à celle de la spécification USB 3.0, elle reste antérieure à celle de la version finale du standard xHCI. Résultat, Microsoft n'a pas souhaité développer de pilote xHCI basé sur les drafts et il n'y a pas de pilote natif fourni dans l'OS pour l'USB 3.0.

Conséquence concrète pour les marques qui vendent des contrôleurs : chaque fabricant doit fournir un pilote qui inclut sa propre implémentation d'une stack xHCI. Un travail redondant mais obligatoire.

Autre point à noter comme nous l'avons expliqué précédemment, par défaut, Windows 7 ne sait pas gérer des périphériques de stockage dans un autre mode d'accès que le mode USB traditionnel (BOT).

Microsoft à cependant été assez proactif sur la question, et propose de contourner cette limitation (voir ce document ) en ajoutant ce que l'on appelle un Class Driver qui se chargera à la volée lorsque l'on connectera un périphérique (le driver xHCI "marquant" le périphérique USB pour qu'il soit géré par le Class Driver UASP). La spécification fournie par Microsoft permet de développer un tel pilote et explique comment réaliser l'accrochage dans les xHCI.

Bien entendu cela n'est pas obligatoire, à tel point qu'aucun des fabricants principaux (Intel, NEC/Renasas, Asmedia, EtronTech) ne fournit de Class Driver UASP avec ses xHCI Windows 7 ! Un tel Class Driver UASP existe cependant, développé par la société MCCI  (qui a participé à l'élaboration de la spécification UASP).


Un fabricant de cartes mères, Asus, fournit d'ailleurs ce pilote avec ses cartes mères via un utilitaire baptisé USB Boost.

Windows 8 : gestion native, ou presque

Si les fabricants de contrôleurs ne se sont pas pressés pour développer des pilotes UASP, c'est avant tout parce que Microsoft avait annoncé qu'il proposerait une stack de pilotes USB 3.0 native pour Windows 8.


Le constructeur a tenu ses promesses comme vous pouvez le voir sur ce schéma. En plus d'un pilote xHCI natif, la stack est complète et inclut un Class Driver supportant à la fois le more BOT et le mode UASP. Cependant, et c'est là que les choses se corsent : le Class Driver UASP ne s'activera pas sur tous les contrôleurs. Sur le point Microsoft est assez peu loquace, indiquant simplement que leur implémentation est universelle, avec si nécessaire une émulation logicielle pour les Streams nécéssaires à l'utilisation de l'UASP. Mais que dans certains cas d'incompatibilités matérielles connus (par Microsoft, et non précisés), l'UASP peut ne pas s'activer.

On voit la différence uniquement en regardant le nom du disque connecté. S'il contient USB drive, le disque fonctionne en mode BOT. S'il contient SCSI drive, il fonctionne en mode UASP.

Nous avons testés les contrôleurs USB 3.0 que nous avions sous la main, et avons vu quelques surprises. Si l'on pensait dans un premier temps que seuls les puces certifiées xHCI 1.0 seraient compatibles UASP, en pratique les choses sont bien plus complexes, voici un résumé de ce que nous avons obtenu pour les modèles que nous avons pu tester. Nous avons également ajouté le niveau de xHCI des autres modèles qui leurs sont liés :


On ne trouvera pas de lien logique entre la version du xHCI du contrôleur et son support ou non de l'UASP. En pratique, seuls les chipsets d'AMD (basés sur le Renasas PD720200) et d'Intel ont permis de charger le driver UASP de Microsoft.

Pour les fabricants tiers taïwanais, c'est par contre une déconvenue, a commencer par le 1042 d'Asmedia, extrêmement répandu sur les cartes mères récentes et qui est incompatible xHCI 1.0. Une version 1042A, compatible xHCI 1.0 a bel et bien été annoncée par le constructeur en octobre dernier , mais ne nous l'avons pour l'instant pas vu chez les constructeurs de cartes mères. On ne sait pas si elle permettra d'activer ou non l'UASP sous Windows 8.

Bien évidement, on sait aussi que l'Asmedia 1042 permet d'utiliser l'UASP via le pilote de MCCI, ce qui rend la situation un peu plus ubuesque !

Le cas d'EtronTech est encore plus surprenant puisque la puce est annoncée compatible xHCI 1.0  sur le site du constructeur. Ce dernier ne parle que de mode isosynchrones et de transferts types contrôles et bulk ce qui pourrait mettre la puce à l'oreille sur une gestion imparfaite des streams.

Autant dire que cela est pour le moins confus pour les utilisateurs. Notez que le pilote xHCI de Microsoft indique, dans le gestionnaire de périphérique, le mode dans lequel il fonctionne via quelques chiffres (on lit "- 0100" pour xHCI 1.0, et "- 0096" pour xHCI 0.96) :


Notez qu'il reste toujours possible pour un constructeur de fournir son propre pilote UASP, même s'ils ne le font pas à l'image de Windows 7. Et donc, tout comme pour Windows 7, MCCI propose lui aussi son propre pilote UASP sous Windows 8. Ce pilote est fourni une fois de plus par Asus.

Maintenant, avoir le bon modèle de contrôleur supporté par Microsoft, un pilote UASP et/ou un Windows compatible ne suffit pas forcément pour que l'UASP soit actif, mais avant de vous expliquer pourquoi, revenons un instant sur les fameux modes Turbo disponibles sur certaines cartes mères.


Page 4 - Le cas des Turbo

Nous en parlons assez régulièrement dans nos tests de cartes mères, les constructeurs proposent diverses solutions pour augmenter les débits de l'USB 3.0, des solutions que l'on résume souvent sous le nom de Turbo.

Avant de voir ce qu'elles font en pratique, un petit rappel. Nous parlons ici de solutions logicielles. Certaines cartes mères proposent en effet dans leur bios une option Turbo.


Celles-ci sont différentes. Dans ce cas (une carte mère Gigabyte), elle consiste à connecter le contrôleur USB 3.0 tiers différemment, il passe alors des lignes PCI Express exposées par le chipset directement vers les lignes gérées par le processeur. Cela permet de lever éventuellement certaines limites, mais cela n'a rien à voir avec ce dont nous vous parlons ci-dessous.

Les solutions logicielles

Nous évoquions précédemment l'application USB Boost d'Asus. Si elle propose un pilote UASP, elle propose également un autre mode de fonctionnement baptisé Turbo, et que l'on avait vu arriver un peu avant chez Asrock via une application baptisée Xfast USB (et encore un peu plus avant chez SuperTalent).


L'idée de base de cet outil est de remplacer à la volée le Class Driver BOT Microsoft par un autre pilote. On ne parlera pas vraiment d'UASP même si, sur le principe de fonctionnement, l'idée n'est pas sans rappeler ce que propose de faire Microsoft pour implémenter l'UASP. En pratique il s'agit d'un pilote optimisé, qui fonctionne dans le cas d'Asrock à la fois sur les périphériques USB 2.0 mais aussi sur les périphériques USB 3.0 (l'application USB Boost ne fonctionne qu'en USB 3.0).

Le fonctionnement de ces applications est littéralement transparent pour les contrôleurs ce qui laisse penser que les fonctionnalités avancées (Stream pipes et autres) ne sont probablement pas utilisées.


A gauche, un port USB 2.0 sans Xfast USB, à droite avec

Dans le cas de Xfast USB, on peut voir sur nos screenshots que l'outil d'Asrock ajoute un ClassDriver baptisé FNETBOH_305.SYS, et qui semble développé par cette société tierce taïwanaise .

Chez Asus, le mode Turbo est un peu plus compliqué puisqu'il remplace plusieurs pilotes Microsoft par des pilotes qui viennent, encore sans surprise, de chez MCCI :


Les pilotes insérés par Asus remplaçent la stack Microsoft

Dans les deux cas, ces pilotes fonctionnent de manière universelle sur tous les contrôleurs, indépendamment de la marque. Ainsi, si l'on prend l'exemple de la carte mère P8Z77-V Pro d'Asus qui dispose à la fois de ports Intel et Asmedia, on pourra activer le mode Turbo sur les deux types de ports. La limite de ces applications tient dans le fait qu'elles ne fonctionnent que sur les cartes mères de leur marque respective.

Notons une limitation de l'outil d'Asus, il n'est pas possible de choisir entre Turbo et UASP. L'application permet simplement de choisir entre le mode normal (BOT) ou un des deux autres modes disponibles, Turbo ou UASP. Si l'UASP est "possible", on ne pourra pas activer le mode Turbo. Notez enfin que le pilote UASP fourni par Asus ne fonctionne qu'avec le contrôleur Asmedia.
Des transferts limités à 64k ?

Comme nous l'avons dit précédemment, il y a une distinction entre ces modes Turbo et l'UASP au sein des applications, si la méthode utilisée (remplacer des drivers Microsoft par un driver custom) est la même, que font réellement ces pilotes ?

Il faut savoir qu'il y a en pratique une limitation dans la taille maximale des I/O qui peuvent être envoyées par les pilotes Microsoft fournis dans Windows 7 aux périphériques USB, cette limite étant de 64 Ko. Microsoft reconnait le problème et propose même un hotfix, optionnel, qui est téléchargeable ici  (une adresse email est nécessaire pour le téléchargement). Sur la page on trouve la clef de la base de registre à changer pour modifier la taille maximale des blocs qui puisse être envoyée (jusqu'à 2 Mo). Sachant que le nombre d'I/O que l'on peut traiter est toujours une limite importante, il est naturel de penser que les 64 Ko entraînent une limite forte aux débits séquentiels maximums que l'on peut atteindre.

Mais les logiciels Turbo d'Asus et d'Asrock se résument-t-ilsdonc à ce simple hotfix ? Non, car malheureusement il ne suffit pas d'installer ce Hotfix Microsoft pour que les performances augmentent ! Vous pouvez le voir ci-dessous ou nous comparons trois cas (mode bot, mode bot + hotfix, mode Turbo) :



[ Mode BOT ]  [ Mode BOT + hotfix ]  [ Mode Turbo ]


Le Hotfix ne sert strictement à rien, et pour cause, pour qu'il fonctionne, il faut que le pilote du périphérique autorise des transferts de blocs de plus de 64 Ko. Hors, les périphériques USB utilisent généralement des pilotes Microsoft… qui sont limités à 64 Ko. Si l'on dispose, c'est le cas de quelques modèles, d'un pilote spécifique pour son boitier USB, que ce pilote est bel et bien prévu pour des blocs de plus de 64 Ko, et du hotfix, alors on peut, théoriquement, émuler ce que font les solutions d'Asrock et d'Asus.

Or comme vous le voyez, les solutions d'Asus/Asrock ne s'embarassent pas de tous ces problèmes, et c'est pour cela qu'ils remplacent directement le pilote Microsoft par un pilote tiers, qui n'est pas mué par les mêmes contraintes. Résultat, on voit sous ATTO que les performances augmentent fortement au-delà de 64Ko en mode Turbo.

Cependant, le remède utilisé par Asus et Asrock a des incidences plus complexes. Le pilote changeant, ce n'est pas que la limite du nombre d'I/O qui évolue. Tous les pilotes ne sont pas égaux et pourront être plus ou moins efficaces, ou plus ou moins optimisés pour certaines tailles de transferts. Comme nous le verrons dans nos benchs en pratique, le pilote en lui-même joue un rôle primordial, et peut faire tout, voir parfois n'importe quoi !


Page 5 - Thermaltake BlacX 5G, configurations de test

Nous l'avons dit un peu plus tôt dans cet article, en théorie la question de l'UASP n'est qu'une question de pilote qui concerne l'OS. En pratique, la réalité est un peu plus complexe puisque la spécification UASP a été publiée en juin 2009 et repose sur des parties optionnelles de la spécification USB 3.0 pour ce qu'il s'agit des périphériques.

Résultat, si l'on prend par exemple l'ASM1051 d'Asmedia , puce qui équipe les boitiers SATA/USB 3.0 que nous utilisons pour nos tests de cartes mères, elle est annoncée sur le site d'Asmedia comme compatible avec la spécification USB 3.0, et la spécification BOT. Dans le cas de nos boitiers, ces derniers ne permettent pas l'utilisation de l'UASP.


Il faut disposer d'un contrôleur compatible, il en existe chez Asmedia par exemple avec le 1051E  qui est annoncé comme compatible UASP.

Nous avons donc cherché à trouver des boitiers intégrant ce modèle de contrôleur SATA/USB 3.0 et nous sommes dirigés vers le Thermaltake BlacX 5G.

Thermaltake BlacX 5G

La question de la compatibilité UASP dépasse cependant le simple choix du modèle. Nous avons pour réaliser notre test acheté deux boitiers Thermaltake BlacX 5G utilisant le chipset SATA 6Gbps/USB 3.0 Asmedia 1051E. Rapidement, nous avons noté beaucoup de problèmes. Un des deux boitiers était pratiquement non fonctionnel, mettant parfois plusieurs minutes à être connecté, et se déconnectant dès le moindre transfert.


L'autre, un peu plus arrangeant, accepte de fonctionner par tranches de plusieurs minutes mais tend à se déconnecter au bout de quelques heures de tests non continus ! Il aura aussi adoré se déconnecter au milieu de nos tests d'écriture, nous obligeant à les refaire plusieurs fois. Bref, il ne s'agit pas particulièrement d'un produit que l'on vous recommandera. Notez au passage, et de manière assez ironique, que le boitier (le modèle fonctionnel) fonctionne "mieux" lorsqu'il est connecté sur un port USB 3.0 Intel, AMD, ou Etron… que sur un port Asmedia 1042 !

En pratique cependant, lorsqu'il fonctionnait, ce boitier ne permettait pas d'activer l'UASP malgré le fait qu'il dispose, théoriquement, de la bonne puce ! Un comble. Pour l'obtenir, il faut en effet flasher le firmware du boitier, ce qui se réalise via un firmware qui n'est plus disponible sur le site du constructeur.

Les contrôleurs USB 3.0 en effet, qu'il s'agisse de ceux des contrôleurs intégrés dans les cartes mères, ou dans les boitiers externes, reposent tous sur un firmware que l'on peut - théoriquement - mettre à jour, mais qui est rarement disponible ! Asmedia ne fournit pas directement ces firmwares aux utilisateurs finaux, seuls ses clients directs (les constructeurs de cartes mères/boitiers) y ont accès et choisissent ou non de les rendre disponibles aux utilisateurs finaux que nous sommes.

Afin de mettre toutes les chances de notre côté, nous avons également flashé le firmware de nos contrôleurs ASM1042 présents sur nos cartes mères dans la dernière versions que nous avons trouvé, à savoir la version 1220E. Nous espérions que ce firmware permette de stabiliser la connexion avec nos boitiers lorsqu'ils étaient branchés sur ces ports, mais en pratique cela n'a rien changé.

Configurations de test

Pour réaliser notre test, nous avons utilisé les configurations suivantes :
Intel Core i5 3570k
Asus P8Z77-V Pro (Chipset USB 3.0 Intel natif et Asmedia ASM1042)
2 x 4 Go DDR3-1600 (9-9-9)

Intel Core i5 3570k
Gigabyte GA-Z68X-UD3H-B3 (EtronTech EJ168)
2 x 4 Go DDR3-1600 (9-9-9)

AMD A8-3550K
Asrock A75 Pro4 (Chipset AMD natif)
2 x 4 Go DDR3-1600 (9-9-9)

Nous mesurons les performances via le boitier cité précédemment, nous y plaçons un SSD OCZ :
Boitier SerialATA 6Gbps/USB 3.0 Thermaltake BlacX 5G
SSD OCZ Vertex 3 MaxIOPS 128 Go (SATA 6Gb/s)

Comme indiqué précédemment, nous utiliserons sur la carte d'Asus les modes Turbo (Intel) et UASP (Asmedia) lorsqu'ils sont disponibles (sous Windows 7 et 8 pour Asmedia, uniquement sous Windows 7 pour l'Intel). Sur la carte d'Asrock nous utiliserons Xfast USB pour utiliser le mode Turbo sous Windows 7. A l'image du contrôleur Intel, le contrôleur d'AMD est directement detecté en mode UASP sous Windows 8

Il sera intéressant en pratique de comparer plusieurs choses. Le pilote UASP de MCCI apporte il un plus sous Windows 7 par rapport au mode Turbo ? Que vaut-il face à la gestion native de WindowS 8 ? L'xHCI de Microsoft intégré à Windows 8 est il plus performant que les solutions xHCI maison développées les constructeurs ?

Pour répondre à ces questions, passons, enfin, aux tests !


Page 6 - Performances sous Windows 7

Afin de réaliser nos tests, nous avons utilisés le logiciel IOmeter afin de mesurer les performances en lecture et en écriture. Nous avons optés pour deux tailles de blocs différentes, des blocs de 2 Mo, représentatifs d'opérations sur de gros fichiers, et des blocs de 4 Ko, représentatifs d'opérations sur de petits fichiers. Indépendamment du scénario, nous faisons varier la taille de la queue de commande (Queue Depth) de 1 à 8. En théorie, les pilotes UASP devraient profiter d'un avantage lorsque l'on augmente cette longueur.

Notez que nous utilisons des données fortement compressibles pour nos tests. Cela à l'avantage de stresser au maximum les interfaces et de nous permettre de déterminer les débits maximums ! Les SSD utilisant un contrôleur Sandforce sont en effet capables de compresser à la volée certains types de données utilisés, principalement, dans les benchmarks. Nous vous renvoyons pour plus de détails sur ce sujet vers notre comparatif de SSD !

Pour résumer, nous allons comparer les sept scénarios suivants sous Windows 7 :
- Boitier connecté sur un port AMD en mode BOT
- Boitier connecté sur un port AMD en mode Turbo (driver Asrock Xfast USB/Fnet)
- Boitier connecté sur un port Asmedia en mode BOT
- Boitier connecté sur un port Asmedia en mode UASP (driver Asus USB Boost/MCCI)
- Boitier connecté sur un port EtronTech en mode BOT
- Boitier connecté sur un port Intel en mode BOT
- Boitier connecté sur un port Intel en mode Turbo (driver Asus USB Boost/MCCI)

Opérations sur blocs de 2 Mo

Commençons par le cas le plus classique, celui de l'utilisation de blocs de 2 Mo. Il simule les opérations sur de gros fichiers et permet de déterminer les débits maximaux théoriques que l'on peut obtenir via les interfaces USB 3.0. Les résultats seront donc assez proches de ceux obtenus dans nos mesures de débits séquentiels (sur un port) dans nos tests de cartes mères. Ils ne sont cependant pas équivalents, pour rappel nous utilisons un boitier différent !


Merci d'utiliser un navigateur compatible HTML5 pour voir le graphique.

[ Lecture ]  [ Ecriture ]

Beaucoup d'enseignements à tirer de ces premiers résultats. Regardons d'abord du côté de l'Asmedia, nous avons mesuré les performances en mode BOT et en mode UASP (on ne peut pas activer le mode Turbo lorsque l'UASP est possible via l'utilitaire d'Asus). Le simple fait de passer du mode BOT à l'UASP permet de gagner environ 70 Mo par secondes en lecture/écriture lorsque l'on est en mode QD1. La différence s'explique assez facilement, au delà de la qualité du pilote UASP de MCCI, il faut rappeler qu'une des volontés derrière le développement de l'UASP était de réduire l'impact du protocole de communication (l'overhead, estimé à environ 20% en mode bot) sur les performances. En écriture, le pilote UASP de MCCI permet au contrôleur d'Asmedia de tutoyer celui d'Intel, tout de même.

Si l'on regarde - toujours sur l'Asmedia - ce qui se passe lorsque l'on augmente le nombre de commandes (QD2 et supérieurs), on voit que si le QD2 apporte un tout petit gain (plus particulièrement en écriture) en mode BOT, il est plus net en UASP même si, au-delà, on ne voit pas de gains. Est on au maximum de ce que peut offrir l'interface, ou est on limité par le pilote ? On verra par la suite ce qui se passe sur des blocs de 4 Ko.

Jetons maintenant un œil du côté des performances des contrôleurs Intel, disponibles en mode BOT (classique) et en mode Turbo via l'utilitaire fourni par Asus. Il s'agit, nous l'avions vus dans nos tests de cartes mères précédemment, du contrôleur qui semble le plus efficace. Il obtient les meilleurs performances, y compris sans Turbo. Notez cependant que les gains apportés par le mode Turbo sont énormes : 130 Mo/s en lecture et 80 en écriture. Et comme précédemment, l'ajout du mode QD2 apporte un petit gain dans les deux scénarios, mais rien qui ne soit réellement significatif ou qui évolue au-delà.

En ce qui concerne le contrôleur AMD, pour rappel d'origine NEC/Renasas et intégré aux chipsets du constructeur, ses performances sont un peu en dessous en mode BOT en lecture, et les moins bonnes du comparatif en écriture. Activer le mode Turbo via Xfast USB permet de gagner 70 Mo/s en lecture, mais en écriture les performances deviennent littéralement folkloriques. Ce n'est pas la première fois que l'on voit des pertes de performances via Xfast USB sur les contrôleurs Renasas, il est possible que cela soit lié aux optimisations utilisées par le pilote.

Terminons enfin sur l'EtronTech, ses performances en lecture et en écriture sont assez modestes, surtout qu'il n'est aidé ici par aucun mode Turbo. L'écart en lecture avec l'Intel en mode Turbo va du simple au double tout de même !

Passons maintenant aux tests sur des blocs de 4 Ko pour voir si la hiérarchie évolue !

Opérations sur blocs de 4 Ko

Nous utilisons cette fois ci des blocs de 4 Ko, simulant des transferts effectués sur de petits fichiers. Il s'agit du scénario qui devrait montrer, s'il y en a un, un gain assez net pour les pilotes UASP lorsque l'on fait varier le QD !


Merci d'utiliser un navigateur compatible HTML5 pour voir le graphique.

[ Lecture ]  [ Ecriture ]

Commençons une fois de plus par l'Asmedia avec une première constatation : activer l'UASP, en mode QD1, ralentit légèrement les débits. Au-delà cependant, on commence à voir très clairement l'intérêt de l'UASP : en QD8, les performances sont tout de même 3.7 plus rapides qu'en mode QD1 ! Ici, l'avantage avec le mode bot est particulièrement net et indiscutable en lecture. Notez que notre boitier Thermaltake a refusé catégoriquement de réaliser notre test d'écriture 4 Ko branché en UASP sur le contrôleur Asmedia

Les autres contrôleurs sont dans un mouchoir, mais il faut noter le cas particulier du contrôleur AMD/Renasas qui offre ici des performances largement au dessus du lot en mode Turbo/Xfast USB. Le driver Asrock/Fnet fait des miracles sur les blocs 4 Ko aussi bien en lecture qu'en écriture. Le problème, c'est que ces performances, bien que constantes sur plusieurs tests, sont au dessus de ce que l'on peut obtenir théoriquement avec le Vertex 3 MaxIOPS. Y a-t-il une astuce dans le pilote qui concatène des accès consécutifs pour maximiser les résultats dans les benchs ? Nous restons méfiants sur ce résultat.

Maintenant que nous avons fait le tour des performances sous Windows 7, il est temps de regarder le cas, plus compliqué, de Windows 8 !


Page 7 - Performances sous Windows 8

Nous utilisons toujours IOmeter pour réaliser des tests identiques à ceux réalisés précédemment sous Windows 7. Il y a cependant quelques différences importantes à noter.

Comme indiqué précédemment, nous utilisons pour nos tests le xHCI générique proposé par Microsoft. Si cela n'est pas forcément recommandé, il est tout de même possible de remplacer cet xHCI par celui fournit par le constructeur. Asmedia fait partie de ceux qui proposent un xHCI compatible Windows 8, nous mesurerons donc, pour le mode BOT, les performances via le xHCI Microsoft et via le xHCI Asmedia. Nous avons également mesuré les performances en UASP via les deux xHCI, ces dernières sont, à la marge d'erreur près, identiques. Pour simplifier la lecture déjà bien complexe de nos graphiques, nous nous contenterons d'afficher les scores utilisant le xHCI Microsoft. Dans le cas d'Asmedia, pour rappel, nous utilisons le pilote UASP de MCCI !

En ce qui concerne le contrôleur d'Intel, nous utilisons le xHCI Microsoft (Intel n'en fournit pas) et mesurons les performances en mode UASP. Sous Windows 8 lorsque l'on utilise l'intégralité de la stack Microsoft (xHCI + Class Driver UASP), la connexion se fait directement dans le mode le plus rapide, il n'est pas possible de simuler les performances en mode BOT, qui n'auraient de toute façon que peu d'intérêt.

Enfin, nous mesurons pour le contrôleur AMD les performances en UASP. Pour résumer cela donne :
- Boitier connecté sur un port AMD en mode UASP, xHCI Microsoft
- Boitier connecté sur un port Asmedia en mode BOT, xHCI Microsoft
- Boitier connecté sur un port Asmedia en mode BOT, xHCI Asmedia
- Boitier connecté sur un port Asmedia en mode UASP MCCI, xHCI Microsoft
- Boitier connecté sur un port EtronTech en mode BOT, xHCI Microsoft
- Boitier connecté sur un port Intel en mode UASP Microsoft, xHCI Microsoft

Opérations sur blocs de 2 Mo

Commençons dans ce scénario qui permet, on le rappelle, de maximiser les débits :


Merci d'utiliser un navigateur compatible HTML5 pour voir le graphique.

[ Lecture ]  [ Ecriture ]

Regardons d'abord du côté de l'Asmedia ou l'on compare deux xHCI différents : l'implémentation Microsoft et celle d'Asmedia. Sur les tests de 2 Mo, le résultat est sans appel : le xHCI de Microsoft domine de manière absolue avec des débits au-delà de 300 Mo ! Les performances de l'xHCI d'Asmedia sous Windows 8 paraissent même assez faibles, mais nous y reviendrons.

Lorsque l'on active l'UASP (via le driver MCCI) sur le contrôleur Asmedia, les choses s'arrangent et l'on atteint, en pointe, des résultats assez proches de ce que l'on avait avec ce même pilote sous Windows 7. Installer un xHCI Asmedia ne change rien aux performances.

Le contrôleur Intel ne fonctionne ici qu'en mode UASP via les pilotes de Microsoft. Et si les résultats sont élevés, ils ne sont tout de même pas délirants comparativement à ce que l'on avait pu observer sous Windows 7. Augmenter le QD n'a quasiment pas d'impact une fois de plus, nous verrons ce qui se passe sur des blocs de 4 Ko. On notera tout de même que le contrôleur Asmedia, via le pilote UASP de MCCI termine devant le contrôleur d'Intel en écriture.

L'autre contrôleur à utiliser l'UASP de Microsoft est celui d'AMD, qui fait une prestation très correcte ici en lecture. Le contrôleur d'EtronTech, detecté en mode BOT uniquement via les pilotes Microsoft ferme la marche en lecture et en écriture (si l'on met de côté le cas particulier de l'Asmedia avec xHCI Asmedia)

Opérations sur blocs de 4 Ko

Que se passe t'il sur des blocs de 4 Ko ? Mettons court au suspens :


Merci d'utiliser un navigateur compatible HTML5 pour voir le graphique.

[ Lecture ]  [ Ecriture ]

Avant de nous atteler à l'UASP Microsoft, revenons sur le contrôleur Asmedia et ses xHCI. Si nous avions noté que l'xHCI de Microsoft était particulièrement bon en mode 2 Mo, ici la situation se retrouve totalement inversée. Les performances en mode BOT via le xHCI de Microsoft sont très basses et le xHCI d'Asmedia fait ici significativement mieux. Si l'on active l'UASP, on notera que les choses s'arrangent nettement et l'on revient à des débits un peu plus dans la norme de ce que l'on avait vu précédemment.

Que dire cependant du cas des autres contrôleurs ? Visiblement, le xHCI de Microsoft n'est pas efficace avec de petits blocs, et cela vaut pour tous les modèles testés via cet xHCI.

Et dans le cas d'Intel et d'AMD, pour lesquels l'UASP est actif rappelons le, les performances sont carrément décevantes. Passé le QD2 cependant, aucun gain à noter ce qui semble indiquer que pour une raison ou pour une autre, le pilote Microsoft UASP ne prend pas en charge le NCQ, contrairement à ce qu'indique la documentation du constructeur et des retours obtenus sur d'autres modèles par certains de nos confrères. Faut-il une version spécifique du firmware de l'ASM1051E pour que le NCQ soit actif sous Windows 8 ? En l'état, nous ne pouvons pas supposer mieux.


Dans tous les cas, le xHCI reste relativement peu performant en QD1 ce qui est tout de même assez dommage !


Page 8 - Récapitulatif

Nous avons mis dans un seul graph les performances de tous les modes que nous avons testés, vous pouvez le consulter ci-dessous. Cela nous permet de comparer les performances sous Windows 7 et 8.

Opérations sur blocs de 2 Mo


Merci d'utiliser un navigateur compatible HTML5 pour voir le graphique.

[ Lecture ]  [ Ecriture ]

Quels enseignements tirer ? Windows 8 ne profite pas à tout le monde. On notera que dans nos tests, le contrôleur d'Intel avec le pilote Turbo d'Asus continue de surclasser tout le monde. Ce qui est plus surprenant, c'est de voir qu'ici, sous Windows 8 avec un pilote UASP Microsoft, les performances sont moindres, on perd 40 Mo/s en lecture et 80 en écriture.

Le pilote de MCCI de son côté fait un très bon travail dans les deux cas avec des performances similaires indépendamment du système.

On notera qu'au final, les contrôleurs qui profitent le plus de l'implémentation USB 3.0 de Windows 8 sont ceux d'EtronTech et d'Asmedia qui gagnent 40 et 70 Mo/s en lecture. Par contre, là ou en écriture le contrôleur d'Asmedia gagne 30 Mo/s, celui d'EtronTech voit ses performances chuter de 100 Mo/s.

Opérations sur blocs de 4 Ko


Si les choses n'étaient pas forcément encourageantes pour Windows 8 sur des blocs de 2 Mo, avec des blocs de 4ko c'est bien pire.


Merci d'utiliser un navigateur compatible HTML5 pour voir le graphique.

[ Lecture ]  [ Ecriture ]

Dans tous les cas en lecture comme en écriture, l'implémentation Windows 8 native (BOT ou UASP) sera plus lente que l'implémentation BOT sous Windows 7, c'est tout de même un comble ! Le cas le plus flagrant est peut être celui du contrôleur Intel qui perd entre 15 et 25 Mo secondes sous Windows 8, malgré un pilote UASP.

N'oublions pas bien entendu le cas AMD en Turbo, ou plus exactement du pilote Fnet utilisé par Xfast USB qui semble "optimiser" nos I/O 4k à la volée en les regroupant dans des accès plus gros. Quelque chose qui aide dans les benchmarks théoriques mais qui n'aidera pas dans les transferts de petits fichiers que nous sommes censés simuler avec ce test.


Page 9 - Conclusion

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…


Copyright © 1997-2024 HardWare.fr. Tous droits réservés.