Comparatif de 20 clefs USB 3.0 128 Go

Publié le 27/10/2014 par
Imprimer
Ce comparatif n'est pas la première fois que nous nous intéressons à la question des performances de l'USB 3.0. Si vous souhaitez creuser le sujet plus en détail, nous vous renvoyons vers cet article : USB 3.0 : xHCI, BOT, UASP, Windows 7 et 8… pas si simple !. Pour les autres, petit rappel nécessaire pour la suite de notre article.

Si l'USB se veut être une interface universelle (voir même le futur connecteur unique !), c'est en partie parce que ses spécifications tentent de standardiser un maximum de choses. Ainsi, pas besoin d'installer un pilote lorsque l'on branche une clef USB, le pilote qui gère l'interface est fourni par le système d'exploitation (l'EHCI pour l'USB 2.0 ou l'xHCI pour l'USB 3.0) indépendamment du modèle de contrôleur, et ce dernier dispose également d'un pilote pour gérer les transferts de données (on parle de mode BOT).

Bulk Only Transport

Disponible depuis 1999 et crée pour l'USB 1.1, le mode de transfert « Bulk » est le mode de fonctionnement par défaut utilisé par l'écrasante majorité des clefs USB disponibles sur le marché. Etant donné son grand âge (le protocole n'a pas évolué avec l'USB 2.0), on ne sera pas surpris de sa simplicité. De manière basique, le mode BOT (parfois appelé BBB) consiste à gérer les commandes de manière séquentielle :


Le schéma ci-dessus montre le cas d'une lecture de données. En vert on note le début de la commande de lecture envoyée par le système. En pratique, les drivers commenceront par envoyer la requête (CBW) et attendront que le périphérique réponde qu'il est bien disponible (ACK sur le schéma ci-dessus, de l'anglais ACKnowledgement) avant d'envoyer la commande pour que démarre effectivement le transfert et que puisse se faire la réception des données, qui arriveront par la suite. Une fois que la commande aura été exécutée, l'hôte interroge le périphérique pour connaitre son état et savoir s'il peut de nouveau envoyer des requêtes.

En pratique, une commande côté système (vert à gauche) se retrouve traduite en trois échanges séquentiels, qui doivent impérativement s'effectuer l'un après l'autre (d'où le « BBB » pour Bulk-Bulk-Bulk, le mode BOT étant une « amélioration » du modèle de commande de l'USB 1.0/1.1 basé sur des interruptions). Si le système parait compliqué, il faut se rappeler que jusqu'à l'USB 2.0, il n'y avait qu'une seule voie pour faire transiter des données dans les deux sens, il faut donc que l'hôte et le périphérique soient synchronisés dans leurs échanges. Le mode BOT sert donc à cela, à l'image d'une route dont une des deux voies est coupée et sur laquelle on aura placée des feux de signalisation pour créer une circulation alternée.

On peut deviner les conséquences pratiques de ce mode de communication. D'abord, on le note à droite sur le schéma, il y'a un certain nombre d'endroits ou le périphérique doit attendre après l'hôte, limitant ses performances théoriques. Nos comparatifs de cartes mères nous ont montré que malgré un débit théorique de 480 Mbit/s (60 Mo/s) pour l'USB 2.0, les transferts de données en pratique peinent en mode BOT à dépasser les 35 Mo/s.

L'autre conséquence est qu'il est impossible en mode BOT de lancer plusieurs commandes en même temps, ou de gérer efficacement des concepts de queues pour les commandes – pourtant essentiels pour tirer un maximum de performances. Les multiples échanges nécessaires rajoutent une latence pendant laquelle le périphérique se tourne les pouces. La dernière conséquence, liée, est qu'il est généralement une excessivement mauvaise idée de tenter de faire deux choses en même temps (écrire un gros fichier et en lire un autre) sur une clef USB. Si les systèmes d'exploitations peuvent gérer plus ou moins bien la situation, en pratique l'USB et son mode BOT n'ont pas été prévus pour la simultanéité.

L'USB 3.0 améliore (un peu) le BOT

Avec l'arrivée de l'USB 3.0, le standard BOT a très légèrement évolué. En pratique le protocole ne change pas, mais il utilise mieux les caractéristiques du nouveau bus. Ainsi, un des changements fondamentaux entre l'USB 2.0 et l'USB 3.0 est que l'on dispose de voies séparées pour la communication dans chaque sens entre le PC et le périphérique. Chacun peut parler en même temps, ce qui améliore très légèrement la latence du mode BOT (qui reste malgré tout séquentiel dans l'exécution de ses commandes). L'autre modification est l'utilisation de stream pipes. Les commandes BOT en USB 3.0 sont désormais encapsulées dans des flux indépendants, qui peuvent être multiples. En pratique donc, on pourra envoyer une lecture et une écriture en simultanée vers un périphérique USB sans créer d'odieuses situations d'attentes.


L'USB 3.0 rajoute la notion de stream pipes pour autoriser des accès en parallèle, mais qui restent séquentiels !

Si ces changements peuvent sembler résoudre beaucoup de problèmes, en pratique ils évitent surtout la catastrophe qu'aurait été le mode BOT sans eux en USB 3.0. Le fait que le protocole BOT reste séquentiel ne résout pas le problème des queues par exemple. L'USB-IF en est conscient et indique d'ailleurs que le mode BOT limite fortement les transferts à un débit de 250 Mo/s environ (dans le meilleur des cas, à savoir de gros fichiers !), soit la moitié de ce dont est capable l'interface, au mieux !
Vos réactions

Top articles