Motivation

Avec un taux de signalisation de 480 Mbits / s, les périphériques USB 2.0 devraient pouvoir transmettre des données à 60 Mo / s maximum. Cependant, les appareils actuels semblent limités à 30-42 Mo / s lors de la lecture de [ Wiki: USB ]. Cela représente 30% de frais généraux.

L'USB 2.0 est un standard de facto pour les périphériques externes depuis plus de 10 ans. Le stockage portable est l’une des applications les plus importantes de l’interface USB. Malheureusement, l'USB 2.0 a rapidement constitué un goulot d'étranglement limitant la vitesse de ces applications exigeantes en bande passante. Un disque dur actuel est par exemple capable de lire plus de 90 Mo / s en lecture séquentielle. Compte tenu de la présence de longue date sur le marché et du besoin constant de bande passante supérieure, nous nous attendons à ce que le système éco USB 2.0 ait été optimisé au fil des ans et ait atteint une performance de lecture proche de la limite théorique.

Quelle est la bande passante maximale théorique dans notre cas? Chaque protocole a un surcoût, y compris USB et, conformément à la norme officielle USB 2.0, 53,248 Mo / s [ 2 , Tableau 5-10]. Cela signifie théoriquement que les périphériques USB 2.0 actuels pourraient être 25% plus rapides.

Une analyse

Pour vous rapprocher de la racine de ce problème, l’analyse suivante montrera ce qui se passe sur le bus lors de la lecture de données séquentielles à partir d’un périphérique de stockage. Le protocole est divisé couche par couche et nous nous intéressons plus particulièrement à la question de savoir pourquoi 53,248 Mo / s est le nombre théorique maximal de périphériques montants en vrac. Enfin, nous parlerons des limites de l’analyse qui pourraient nous donner des indices de frais généraux supplémentaires.

Remarques

Tout au long de cette question, seuls les préfixes décimaux sont utilisés.

Un hôte USB 2.0 est capable de gérer plusieurs périphériques (via des concentrateurs) et plusieurs terminaux par périphérique. Les points d'extrémité peuvent fonctionner dans différents modes de transfert. Nous limiterons notre analyse à un seul périphérique directement connecté à l'hôte et capable d'envoyer en continu des paquets complets sur un noeud final en vrac en mode haute vitesse.

Encadrement

La communication USB haute vitesse est synchronisée dans une structure de trame fixe. Chaque trame a une longueur de 125 us et commence par un paquet de début de trame (SOF). Elle est limitée par une séquence de fin de trame (EOF). Chaque paquet commence par SYNC et se termine par et End-Of-Packet (EOF). Ces séquences ont été ajoutées aux diagrammes pour plus de clarté. EOP est de taille variable et dépend des données de paquet. Pour SOF, il s'agit toujours de 5 octets.

Ouvrez l'image dans un nouvel onglet pour voir une version plus grande.

Transactions

USB est un protocole piloté par un maître et chaque transaction est initiée par l'hôte. L’intervalle de temps entre SOF et EOF peut être utilisé pour les transactions USB. Cependant, le calendrier des SOF et des EOF est très strict et l’hôte n’initie que des transactions pouvant être entièrement exécutées dans le créneau disponible.

La transaction qui nous intéresse est une transaction en bloc réussie. La transaction commence par un paquet de jetons IN, puis les hôtes attendent un paquet de données DATA0 / DATA1 et confirment la transmission avec un paquet de prise de contact ACK. L'EOP pour tous ces paquets est compris entre 1 et 8 bits, en fonction des données de paquet, nous avons supposé le cas le plus défavorable ici.

Entre chacun de ces trois paquets, nous devons tenir compte des temps d’attente. Celles-ci se situent entre le dernier bit du paquet IN provenant de l'hôte et le premier bit du paquet DATA0 du périphérique et entre le dernier bit du paquet DATA0 et le premier bit du paquet ACK. Nous n’avons pas à prendre en compte d’autres retards car l’hôte peut commencer à envoyer le prochain IN juste après l’envoi d’un ACK. Le temps de transmission par câble est défini à 18 ns au maximum.

Un transfert en masse peut envoyer jusqu'à 512 octets par transaction IN. Et l'hôte essaiera d'émettre autant de transactions que possible entre les délimiteurs de trame. Bien que le transfert en vrac ait une priorité basse, il peut prendre tout le temps disponible dans un créneau lorsqu'aucune autre transaction n'est en attente.

Pour garantir une récupération d’horloge correcte, les normes définissent un bourrage de bits d’appel de méthode. Lorsque le paquet nécessite une très longue séquence de la même sortie, un flanc supplémentaire est ajouté. Cela garantit un flanc après un maximum de 6 bits. Dans le pire des cas, la taille totale du paquet augmenterait de 7/6. L'EOP n'est pas sujet au bourrage.

Ouvrez l'image dans un nouvel onglet pour voir une version plus grande.

Calculs de bande passante

Une transaction en bloc IN a un temps système de 24 octets et une charge utile de 512 octets. C'est un total de 536 octets. La plage horaire comprise entre 7487 octets est large. Sans avoir besoin de bits, il reste de la place pour 13.968 paquets. Avec 8000 Micro-images par seconde, nous pouvons lire les données avec 13 * 512 * 8000 B / s = 53.248 Mo / s.

Pour des données totalement aléatoires, nous nous attendons à ce qu'un bourrage de bits soit nécessaire dans l'une des 2 ** 6 = 64 séquences de 6 bits consécutifs. C'est une augmentation de (63 * 6 + 7) / (64 * 6). En multipliant tous les octets sujets au bourrage sur les bits, vous obtenez une longueur totale de transaction de (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537,38 octets. Ce qui donne 13.932 paquets par Micro-Frame.

Un autre cas particulier manque dans ces calculs. La norme définit un temps de réponse maximal du dispositif de 192 temps de bit [ 2 , chapitre 7.1.19.2]. Ceci doit être pris en compte pour décider si le dernier package s’intègre toujours dans la trame au cas où le dispositif aurait besoin du temps de réponse complet. Nous pourrions en tenir compte en utilisant une fenêtre de 7439 octets. La bande passante résultante est cependant identique.

Ce qui reste

• La détection d'erreur et la récupération n'ont pas été couvertes. Peut-être que les erreurs sont assez fréquentes ou que la récupération d’erreur prend suffisamment de temps pour avoir un impact sur les performances moyennes.

• Nous avons supposé une réaction instantanée de l'hôte et du périphérique après les paquets et la transaction. Personnellement, je ne vois pas le besoin de grosses tâches de traitement à la fin des paquets ou des transactions de part et d’autre et je ne vois donc aucune raison pour laquelle l’hôte ou le périphérique ne serait pas en mesure de répondre instantanément avec des implémentations matérielles suffisamment optimisées. Surtout en fonctionnement normal, la plupart des tâches de tenue de livre et de détection d'erreur peuvent être effectuées pendant la transaction et les paquets et la transaction suivants peuvent être mis en file d'attente.

• Les transferts pour d'autres points de terminaison ou des communications supplémentaires n'ont pas été pris en compte. Peut-être que le protocole standard pour les périphériques de stockage nécessite une communication à canal latéral continu qui consomme un temps précieux.

• Il peut y avoir une surcharge de protocole supplémentaire pour les périphériques de stockage pour le pilote de périphérique ou la couche de système de fichiers. (charge utile du paquet == données de stockage?)

Question

• Pourquoi les implémentations actuelles ne sont-elles pas capables de diffuser en continu à 53 Mo / s?

• Où est le goulot d'étranglement dans les implémentations d'aujourd'hui?

Et un suivi potentiel: pourquoi personne n’a-t-il tenté de supprimer un tel goulet d’étranglement?

Les références

[1] La spécification officielle USB 2.0

[2] Rapide pdf miroir de la spécification

À un moment de ma vie, je dirigeais le secteur USB pour une grande entreprise de semi. Le meilleur résultat dont je me souvienne est un contrôleur NEC SATA capable de transmettre un débit de données réel de 320 Mbps pour le stockage de masse. Les disques SATA actuels sont probablement capables de le faire, voire légèrement plus. Cela utilisait BOT (un protocole de stockage de masse fonctionne sur USB).

Je peux donner une réponse technique détaillée mais je suppose que vous pouvez en déduire vous-même. Ce que vous devez voir, c’est que, c’est un jeu d’écosystème, toute amélioration significative nécessiterait de la part de Microsoft, par exemple, de modifier sa pile, d’optimiser, etc., ce qui ne se produira pas. L'interopérabilité est beaucoup plus importante que la rapidité. Parce que les piles existantes couvrent soigneusement les erreurs de nombreux périphériques, car lorsque la spécification USB2 est sortie, les périphériques initiaux ne sont probablement pas vraiment conformes à la spécification, car la spécification était boguée, le système de certification l'était, etc., etc. Si vous construisez un système de brassage à domicile à l'aide de Linux ou de pilotes d'hôte USB personnalisés pour MS et d'un contrôleur de périphérique rapide, vous pouvez probablement vous approcher des limites théoriques.

En termes de streaming, l’ISO est supposé être très rapide mais les contrôleurs ne l’implémentent pas très bien, puisque 95% des applications utilisent le transfert en masse.

Par exemple, si vous construisez un circuit intégré de moyeu aujourd'hui, si vous suivez les spécifications à la lettre, vous ne vendrez pratiquement rien. Si vous connaissez tous les bugs sur le marché et assurez-vous que votre IC central peut les tolérer, vous pouvez probablement entrer sur le marché. Je suis toujours étonné de constater à quel point l’USB fonctionne bien compte tenu du nombre de logiciels et de puces de mauvaise qualité.

C'est un sujet très ancien, mais il n'a pas encore de réponse. Ceci est ma tentative:

Pourquoi les implémentations actuelles ne sont-elles pas capables de diffuser en continu à 53 Mo / s?

Les calculs sont presque parfaits, mais vous oubliez quelques éléments dans le nombre d'octets disponibles entre les marqueurs d'image:

1. Chaque micro-trame a deux seuils appelés EOF1 et EOF2. Aucune activité de bus ne doit avoir lieu à / après EOF1. Le placement de ce point est une chose compliquée, mais la position typique est de 560 bits avant le prochain SOF. Un hôte doit planifier ses transactions de manière à ce que toute réponse possible du canal n'atteigne pas ce seuil. Qui mange environ 70 octets sur vos 7487 octets calculés.

2. Vous supposez "données aléatoires". Ceci est complètement non fondé, les données peuvent être n'importe quoi. Par conséquent, l'hôte doit planifier les transactions pour la charge utile la plus défavorable, avec une surcharge de bourrage de bits maximale de 512 * 7/6 = ~ 600 octets. Plus 24 octets de temps de transaction, comme vous l'avez calculé à juste titre. Cela donne (7487-70) / 624 = 11,88 transactions par micro-image.

3. L'hôte doit réserver environ 10% de la bande passante pour les transactions de contrôle pour toute autre activité. Nous obtenons donc environ 10,7 transactions.

4. Le contrôleur hôte a également une certaine latence lors de la gestion de sa liste chaînée, ce qui crée un écart supplémentaire entre les transactions.

5. Le périphérique peut se trouver à 5 concentrateurs / sauts loin de la racine et le délai de réponse peut atteindre 1 700 ns, ce qui nécessite encore 106 octets de chaque budget de transaction. Dans l’estimation brute, il n’effectue que 10,16 transactions par trame, sans compter la bande passante réservée.

L’hôte ne peut pas effectuer de nouvelle planification adaptative en fonction de l’arrivée réelle des transactions dans l’uFrame; il serait prohibitif du point de vue logiciel. Le pilote utilise donc la planification la plus prudente, jusqu’à 9 transactions en bloc par uFrame, ce qui représente 36 Mo / octet. seconde. C’est ce qu’une très bonne clé USB peut offrir.

Certains repères artificiels fous peuvent aller jusqu'à 11 transactions par cadre, ce qui en fait 44 Mbps. Et c'est le maximum absolu pour le protocole HS USB.

Où est le goulot d'étranglement dans les implémentations d'aujourd'hui?

Comme on peut le voir ci-dessus, il n’ya pas de goulot d’étranglement, tout l’espace de temps en bits brut est consommé par la surcharge du protocole.