Eh bien, la première chose à observer est que le mode USB haut débit ne peut pas réellement transférer à 60 Mo/s. Ce chiffre est techniquement la vitesse nominale de l'interface, 480Mb/s, convertie en MB/s, mais c'est la vitesse physique du fil de bas niveau.
Reculons une seconde et regardons ce qu'est réellement l'USB. Votre connecteur USB 1.x/2.x typique comporte quatre fils : +5Vdc, D+, D-, et GND. Vous avez donc une alimentation de 5Vdc et un seul fil différentiel pour l'ensemble du protocole et du transfert de données. La signalisation différentielle est destinée à l'intégrité des données - la même information est envoyée sur D+ et D-, mais la polarité est inversée. Au niveau du récepteur, cela permet de filtrer tout le bruit de "mode commun" - le bruit qui a affecté chaque fil de la même manière -.
Prenez maintenant en considération le débit binaire de 480Mb/s... si je transmets à ce débit sur ce qui est effectivement un seul fil, le récepteur à l'autre extrémité doit échantillonner ces données avec une horloge quelconque... comment sait-il où se trouvent les transitions de données ? Comme dans à peu près tous les transferts de données, les données sur USB sont transmises de manière synchrone - les changements de données se produisent de manière prévisible sur la base d'un signal d'horloge.
Dans un bus parallèle, comme PCI, il y a un signal d'horloge réel sur le bus, et toutes les transitions sur ce bus sont synchronisées par rapport à l'horloge PCI. Mais sur un bus série comme l'USB, il n'y a effectivement qu'un seul fil, qui doit envoyer efficacement à la fois les données et les informations d'horloge.
Il s'avère que l'USB, et en fait la plupart des bus série modernes à haut débit, utilisent un couple de protocoles de données avancés qui permettent au récepteur de déduire les informations d'horloge du flux de données. Il y a une boucle à verrouillage de phase à l'extrémité du récepteur qui se synchronise sur les changements dans les données série entrantes. Pour que cela fonctionne bien, cependant, les données doivent avoir des transitions régulières - envoyer trop de zéros ou trop de uns à la suite permettrait à l'horloge du récepteur de dériver par rapport à l'horloge de l'émetteur.
Donc pour l'un, l'USB sur fil utilise un protocole appelé NRZI. La polarité du signal ne représente pas directement des 1 et des 0, mais change. L'état actuel est maintenu si le bit de données est un 1, l'état actuel est changé sur 0. NRZI est un moyen de transmission efficace, mais il ne garantit pas à lui seul que le signal change assez souvent pour que les PLL restent synchronisées. Vous pouvez imaginer une longue chaîne de 0, qui entraînerait une transition d'état pour chaque horloge binaire. Mais une longue chaîne de 1 n'entraînerait, sans aide supplémentaire, aucun changement. Pour cette raison, l'USB utilise une technique appelée "bit stuffing" (bourrage de bits)... elle ajoute une transition supplémentaire après six bits "1" d'affilée, ce qui entraîne bien sûr une inversion de la polarité des données. À cause de cela, le débit de données le plus défavorable est en fait 6/7e de celui du meilleur débit, soit 411Mb/s = 51MB/s (merci à Per Oresjo pour la correction... j'avais mis ici des trucs sur l'USB 3.0 qui ne sont vraiment pas dans l'USB 2.0).
Mais ce n'est pas tout. Encore une fois, sur un bus parallèle, il y a des signaux supplémentaires pour la gestion du bus. Certains ont des signaux d'adresse et de données séparés, des signaux d'arbitrage de bus, des signaux d'interruption, des signaux de type de transaction de bus, etc. Ceci est géré sur chaque type de bus série en définissant une sorte de paquet de données. Vous trouverez cela sur USB, Ethernet, PCI Express, Firewire, et même sur l'ancien bus I2C à deux fils.
Maintenant, avant d'aller trop loin, considérez que l'USB prend en charge les transferts isochrones - c'est-à-dire un transfert dont les caractéristiques temporelles sont garanties. À l'époque du bus ISA, il était assez difficile d'obtenir le bon fonctionnement de quelque chose d'aussi simple qu'une carte son. Les meilleures d'entre elles devaient disposer de grands tampons de mémoire pour faire face au comportement saccadé du bus. Les transferts USB intègrent le temps comme un fondamental, et à ce titre, fonctionnent très bien avec l'audio et d'autres exigences de données en temps réel.
Un résultat de ceci est que les transferts de paquets sont construits autour du temps. L'USB a un temps de trame de 1ms. Les transferts plus lents sont basés autour de ces trames de 1ms. Les transferts à grande vitesse décomposent la trame en huit microtrames, chacune d'une longueur de 125μs. C'est bien sûr aussi par contrôleur hôte. Il est fort probable que dans votre PC, vous ayez un ou deux contrôleurs hôtes alimentant quatre, huit, voire plus de ports USB. Ainsi, le transfert maximal possible est probablement divisé de différentes manières. Et oui, même le fait de déplacer votre disque sur un port différent peut éventuellement l'accélérer.
Il existe différents types de transferts sur USB. Le premier est le transfert de contrôle, qui est à peu près juste des communications entre l'hôte USB et la cible USB, à haute vitesse mais avec un contenu de données assez faible, utilisé pour les configurations. Le transfert isochrone, qui garantit la bande passante sur le bus. Vous en avez besoin pour l'audio, la vidéo, etc. Un point d'extrémité isochrone à haute vitesse/haute bande passante peut transférer des paquets de 1024 octets à un pic de 192Mb/s, soit 24MB/s. Vient ensuite le transfert par interruption, qui garantit certains timings de latence, et qui est surtout utilisé pour les applications à faible bande passante qui génèrent des données à intervalles aléatoires.
Et enfin, il y a le mode de transfert en masse. C'est celui qui nous intéresse ici. Il est basé sur des paquets de 512 octets, jusqu'à 13 paquets de ce type envoyés par microtrame. Ainsi, un taux de transfert maximum théorique, ignorant tous les autres types de paquets, fournit 512 octets * 13 microtrames * 8 microtrames/trame * 1000 trames/seconde = 53 MB/s. Il est également assez courant que les contrôleurs USB n'autorisent que 10 ou 8 paquets par microtrame, ce qui donne des pics de 41 Mo/s ou 33 Mo/s, respectivement.
Et il est également important de noter que les paquets en vrac obtiennent d'utiliser "tout ce qui reste" sur le bus USB. Pour un lecteur, il va y avoir des paquets d'interruption (le lecteur dit à l'hôte USB qu'il a les données prêtes à être transférées), des paquets de contrôle (l'hôte dit à l'une des cibles sur votre bus USB ce qu'il va faire) et peut-être d'autres choses comme des paquets isochrones (avez-vous une souris ou un clavier sur le même hub) qui ont toujours la priorité sur les paquets de transfert en vrac. Donc votre kilométrage peut, comme d'habitude, varier.
Voir plus ici : http://sdphca.ucsd.edu/Lab_Equip_Manuals/usb_20.pdf
Et c'est juste l'USB. Votre périphérique réel peut avoir d'autres problèmes. Les disques durs ont une latence pour les recherches, les lecteurs flash ne lisent pas nécessairement aussi vite que l'interface USB, etc. Il y a aussi un petit peu de surcharge du système d'exploitation, bien que dans les ordinateurs modernes, ce ne soit pas grand-chose.