2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Cet article explique comment gérer soigneusement la bande passante USB. Chaque pilote client USB est chargé de minimiser la bande passante USB qu'il utilise et de restituer la bande passante inutilisée au pool de bande passante disponible le plus rapidement possible.
Ici, nous pensons que la vitesse de l'USB 2.0 est de 480 Mbps, 12 Mbps et 1,5 Mbps, ce qui correspond respectivement à une vitesse élevée, une vitesse maximale et une vitesse faible. Mais en fait, la bande passante de l'USB 2.0 est très étroite. des prémisses de cet article. L'USB 3.0 semble Cela atténue le problème de bande passante, mais le problème de bande passante n'est pas une limite supérieure insuffisante mais un problème d'hibiscus de planification.
La concurrence pour la bande passante sur le bus USB provient de plusieurs sources, notamment matérielles et logicielles. Il est difficile de prédire avec précision la quantité de bande passante disponible pour un pilote client USB. Les contrôleurs hôtes USB nécessitent une certaine quantité de bande passante pour fonctionner. La quantité requise dépend du fait que le contrôleur soit à grande vitesse. Cela varie d’un système à l’autre. Les hubs USB qui fonctionnent à haut débit doivent parfois traduire des transactions entre des ports amont à haut débit et des périphériques aval à faible vitesse, et ce processus de traduction consomme de la bande passante. Cependant, le fait que la conversion de transactions nécessite ou non de la bande passante dépend du type d'appareil connecté et de la topologie de l'arborescence des appareils.
La pression la plus importante sur les ressources de bande passante provient généralement des pilotes clients USB qui monopolisent la bande passante. Le système alloue la bande passante selon le principe du premier arrivé, premier servi. Si le premier pilote USB chargé demande toute la bande passante disponible, les pilotes USB suivants chargés n'autoriseront aucune bande passante à leurs appareils. Le système ne peut pas configurer ou énumérer le périphérique. La raison de l’échec de l’énumération n’étant pas évidente, l’expérience utilisateur est médiocre.
Parfois, les pilotes clients épuisent la bande passante disponible via des transferts d'interruption à grande vitesse. Mais le scénario de loin le plus courant est que le pilote client alloue trop de bande passante pour un transfert constant et ne parvient pas à la libérer en temps opportun. Le système conserve la bande passante allouée jusqu'à ce que le pilote qui l'a demandé ferme son point de terminaison en ouvrant un autre point de terminaison, ou jusqu'à ce que le périphérique auquel la bande passante lui a été attribuée soit supprimé. Le système n'alloue pas de bande passante garantie pour les transferts en masse, de sorte que les transferts en masse ne sont jamais la cause d'échecs d'énumération. Cependant, les performances d'un périphérique de transfert de masse dépendent de la quantité de bande passante allouée au périphérique pour les transferts réguliers (attentes et interruptions constantes).
La spécification USB 2.0 exige que les périphériques constants aient des points de terminaison à bande passante nulle sur leurs paramètres d'interface par défaut. Cela garantit qu'aucune bande passante n'est réservée au périphérique jusqu'à ce que le pilote de fonction ouvre une interface autre que celle par défaut, ce qui permet d'éviter les échecs d'énumération dus à des demandes excessives de bande passante lors de la configuration du périphérique. Cela n'empêche pas les pilotes clients d'allouer une bande passante excessive après avoir configuré leurs appareils, empêchant ainsi d'autres appareils de fonctionner correctement.
La clé d'une bonne gestion de la bande passante est que chaque périphérique USB du système qui effectue des transferts constants doit fournir plusieurs paramètres alternatifs (Alt) pour chaque interface contenant des points de terminaison constants, et le pilote client doit utiliser ces paramètres Alt à bon escient. Les pilotes clients doivent d’abord demander le paramètre d’interface avec la bande passante la plus élevée. Si la requête échoue, le pilote client doit demander les paramètres d'interface avec des bandes passantes de plus en plus petites jusqu'à ce que la requête aboutisse.
Par exemple, supposons qu'un appareil webcam possède l'interface suivante :
Interface 0 (paramètres d'interface par défaut : il n'y a aucun point de terminaison avec une bande passante constante non nulle dans les paramètres par défaut)
Const Endpoint 1 : taille maximale du paquet = 0 octet
Const Endpoint 2 : taille maximale du paquet = 0 octet
Interface 0 Alt Réglage 1
Const Endpoint 1 : taille maximale du paquet = 256 octets
Const Endpoint 2 : taille maximale du paquet = 256 octets
Interface 0 Alt Réglage 2
Const Endpoint 1 : taille maximale du paquet = 512 octets
Const Endpoint 2 : taille maximale du paquet = 512 octets
Le pilote de la webcam configure la webcam pour utiliser les paramètres d'interface par défaut lors de l'initialisation. Les paramètres par défaut n'ont pas de bande passante constante, donc l'utilisation des paramètres par défaut lors de l'initialisation évite le risque que la webcam ne puisse pas énumérer en raison d'un échec de demande de bande passante constante.
Lorsque le pilote client est prêt à effectuer des transferts isochrones constants, il doit essayer d'utiliser le paramètre Alt 2, car le paramètre Alt 2 a la plus grande taille de paquet. Si la demande échoue, le pilote peut réessayer en utilisant le paramètre Alt 1. Étant donné que le paramètre Alt 1 nécessite moins de bande passante, cette requête peut réussir même si la première requête échoue. Plusieurs paramètres Alt permettent au conducteur de faire plusieurs tentatives avant d'abandonner.
Une fois que la webcam devient inactive, la bande passante allouée peut être restituée au pool de bande passante disponible en sélectionnant à nouveau les paramètres par défaut.
Les utilisateurs peuvent voir la quantité de bande passante allouée par un contrôleur USB en vérifiant les propriétés du contrôleur dans le Gestionnaire de périphériques Windows. Sélectionnez les propriétés du contrôleur et regardez sous l'onglet Avancé. Cette lecture n'indique pas la quantité de bande passante allouée par le hub USB à la traduction des transactions.
La fonctionnalité du Gestionnaire de périphériques qui signale l'utilisation de la bande passante du contrôleur USB ne fonctionne pas correctement sous Windows XP.
La taille maximale de transfert spécifie une limite codée en dur dans la pile de pilotes USB. Les tailles de transfert inférieures à ces limites peuvent échouer en raison des limitations des ressources système. Pour éviter ce type de pannes et assurer la compatibilité avec toutes les versions de Windows, évitez d'utiliser des tailles de transfert importantes pour les transferts USB.
Le membre MaximumTransferSize de la structure USBD_PIPE_INFORMATION est obsolète. La pile de pilotes USB ignore la valeur de MaximumTransferSize pour les périphériques composites et non composites.
Sous Windows 2000, la pile de pilotes USB initialise MaximumTransferSize à USBD_DEFAULT_MAXIMUM_TRANSFER_SIZE. Les pilotes clients peuvent définir une valeur plus petite lors de la configuration du périphérique. Pour les périphériques composites, les pilotes clients par fonction peuvent uniquement modifier la taille maximale de transfert du canal dans les paramètres d'interface autres que ceux par défaut.
La taille du transfert USB est limitée par :
La limitation de la taille de transfert à l'aide de MaximumTransferSize n'affecte pas directement la bande passante consommée par l'appareil. Le pilote client doit modifier les paramètres d'interface ou limiter la taille maximale des paquets définie dans le membre MaximumPacketSize de USBD_PIPE_INFORMATION.
La taille maximale des paquets est définie par le champ wMaxPacketSize du descripteur de point de terminaison. Les pilotes clients peuvent ajuster la taille du paquet USB dans certaines requêtes d'interface adressées au périphérique. La modification de cette valeur ne modifie pas wMaxPacketSize sur le périphérique.
Dans l'URB demandé se trouve la structure USBD_PIPE_INFORMATION du canal. Dans cette structure,
Lorsqu'un pilote client émet une demande de lecture, le tampon de transmission doit être un multiple de la taille maximale du paquet. Même si le pilote nécessite moins de données que la taille maximale du paquet, il doit quand même demander l'intégralité du paquet. Le transfert est terminé lorsque l'appareil envoie un paquet plus petit que la taille maximale (paquet court).
Sur les contrôleurs plus anciens, les pilotes clients peuvent remplacer ce comportement. Dans le membre TransferFlags de l'URB de transfert de données, le pilote client doit définir l'indicateur USBD_SHORT_TRANSFER_OK. Cet indicateur permet au périphérique d'envoyer des paquets plus petits que wMaxPacketSize.
Sur les contrôleurs hôtes xHCI, USBD_SHORT_TRANSFER_OK ignore les points de terminaison en masse et les points de terminaison d'interruption. La transmission de paquets courts sur le contrôleur EHCI ne provoque pas de condition d'erreur.
Sur les contrôleurs hôtes EHCI, USBD_SHORT_TRANSFER_OK est ignoré pour les points de terminaison en masse et d'interruption.
Sur les contrôleurs hôtes UHCI et OHCI, si USBD_SHORT_TRANSFER_OK n'est pas défini pour les transferts en masse ou par interruption, les transferts de paquets courts arrêteront le point de terminaison et renverront le code d'erreur du transfert.
Le pilote de pile de pilotes USB impose des limites différentes sur la taille des paquets lors de l'écriture sur un périphérique et lors de la lecture à partir du périphérique. Certains pilotes clients doivent fréquemment transmettre de petites quantités de données de contrôle pour gérer leurs appareils. Dans ce cas, il n’est pas pratique de limiter le transfert de données à des paquets de taille uniforme. Par conséquent, lors de l’écriture des données, la pile de pilotes n’attribue aucune signification particulière aux paquets dont la taille est inférieure à la taille maximale du point de terminaison. Cela permet au pilote client de diviser les transferts volumineux vers le périphérique en plusieurs URB de taille inférieure ou égale au maximum.
Le pilote doit terminer le transfert avec un paquet plus petit que la taille maximale, ou utiliser un paquet de longueur nulle pour délimiter la fin du transfert. Le transfert n'est pas terminé tant que le pilote n'envoie pas un paquet plus petit que wMaxPacketSize. Si la taille du transfert est exactement un multiple de la valeur maximale, le pilote doit envoyer un paquet délimité de longueur nulle pour terminer explicitement le transfert.
Comme l'exige la spécification USB, le pilote client est chargé de délimiter les transferts de données à l'aide de paquets de longueur nulle. La pile de pilotes USB ne génère pas automatiquement ces paquets.
Les pilotes USB 2.0 et USB 1.1 compatibles doivent transmettre un paquet de taille maximale (wMaxPacketSize), puis terminer la transmission avec un paquet inférieur à la taille maximale, ou utiliser un paquet de longueur nulle pour délimiter la fin de la transmission. Le transfert n'est pas terminé tant que le pilote n'envoie pas un paquet plus petit que wMaxPacketSize. Si la taille du transfert est exactement un multiple de la valeur maximale, le pilote doit envoyer un paquet délimité de longueur nulle pour terminer explicitement le transfert.
Le pilote de périphérique est chargé de délimiter les transferts de données à l'aide de paquets de longueur nulle, comme l'exige la spécification USB. La pile USB du système ne génère pas automatiquement ces paquets.
Il se consacre à la recherche technologique depuis plus de 30 ans et maîtrise divers langages tels que java, linux, javascript, php, css, etc. Il a apporté de nombreuses contributions dans le domaine de l'open source. station de documentation pour les développeurs pour partager certains problèmes de développement technologique pour référence future.
