PB cascade de concentrateur hub USB2
Fermé
fleclair
-
3 juil. 2004 à 19:32
peps Messages postés 2216 Date d'inscription vendredi 8 septembre 2000 Statut Contributeur Dernière intervention 26 juillet 2012 - 30 juil. 2004 à 17:05
peps Messages postés 2216 Date d'inscription vendredi 8 septembre 2000 Statut Contributeur Dernière intervention 26 juillet 2012 - 30 juil. 2004 à 17:05
A voir également:
- PB cascade de concentrateur hub USB2
- Liste déroulante en cascade - Guide
- Hub de commentaires background task host ✓ - Forum Windows
- Chat hub - Télécharger - Outils pour navigateurs
- Hub chronopost ile de france colis en cours d'acheminement - Forum Consommation & Internet
- Delete cascade sql - Forum Programmation
5 réponses
peps
Messages postés
2216
Date d'inscription
vendredi 8 septembre 2000
Statut
Contributeur
Dernière intervention
26 juillet 2012
251
3 juil. 2004 à 19:48
3 juil. 2004 à 19:48
Bonjour,
Le problème est posé à l'envers:
Sachant que les fichiers correctifs du XP pour les USB 2.0, ne concerne que les ports intégrés à la CM, il faut donc monter un driver spécifique pour ton concentrateur PEABIRD USB 2.0; par défaut WINXP ne gère que les périphériques USB1.1 en standard.
Le problème est posé à l'envers:
Sachant que les fichiers correctifs du XP pour les USB 2.0, ne concerne que les ports intégrés à la CM, il faut donc monter un driver spécifique pour ton concentrateur PEABIRD USB 2.0; par défaut WINXP ne gère que les périphériques USB1.1 en standard.
peps
Messages postés
2216
Date d'inscription
vendredi 8 septembre 2000
Statut
Contributeur
Dernière intervention
26 juillet 2012
251
11 juil. 2004 à 21:04
11 juil. 2004 à 21:04
Bonjour,
Concernant la différence entre le 1.0, le 1.1, et le 2.0; il faut comprendre que ces chiffres indiquent plusieurs choses:
a) Ils précisent la version du pilote; Un pilote est un logiciel faisant la liaison entre le système d'exploitation et un périphérique donné.
Ainsi nous avons ici la première version (1.0), puis sa correction de bugs (1.1, le 1 après le point indique un apport correctif); Et la deuxième version (2.0).
b) L'indication 1. et 2. précise que certaines fonctionnalités ont été intégrées directement au gestionnaire (chips du matériel) pour améliorer les performances de celui-ci (temps de réponse, taux de transfert de données traitées).
Maintenant, ces points étant définis partiellement, entrons dans la deuxième partie, tes correctifs:
Q810400= correctif extrait du SP2 (Service Pack 2) pour WIN XP, concernant principalement "la reprise en charge de périphériques USB, montés en aval d'un concentrateur externe après que celui-ci ait été débranché du contrôleur hôte". Donc, orientation principal: l'alimentation; Pas mal, mais à côté.
kb822603= Mise à jour extrait du SP2 pour XP, relatives principalement au partage des ressources alimentations; Mieux, mais tu n'as pas lu la page jusqu'au bout: L'IAD et "La gestion de périphériques à bande passante élevée", ne sont pas traités. Bête, c'est exactement la base de ton problème.
Soit une donnée qui doit passer du tampon d'un hub interne au tampon du hub externe, et retourner l'action voulu dans le même délai. Normalement d'un 2.0 à un 1.1, tu as une commande "WAIT" qui pallie le ralentissement des bus, là ton délai étant équivalent à zéro car tes hub tournent au même rythme, celui en aval déconnecte pour cause d'inactivitée. Ce n'est donc pas un problème matériel, mais mathématique.
Concernant la différence entre le 1.0, le 1.1, et le 2.0; il faut comprendre que ces chiffres indiquent plusieurs choses:
a) Ils précisent la version du pilote; Un pilote est un logiciel faisant la liaison entre le système d'exploitation et un périphérique donné.
Ainsi nous avons ici la première version (1.0), puis sa correction de bugs (1.1, le 1 après le point indique un apport correctif); Et la deuxième version (2.0).
b) L'indication 1. et 2. précise que certaines fonctionnalités ont été intégrées directement au gestionnaire (chips du matériel) pour améliorer les performances de celui-ci (temps de réponse, taux de transfert de données traitées).
Maintenant, ces points étant définis partiellement, entrons dans la deuxième partie, tes correctifs:
Q810400= correctif extrait du SP2 (Service Pack 2) pour WIN XP, concernant principalement "la reprise en charge de périphériques USB, montés en aval d'un concentrateur externe après que celui-ci ait été débranché du contrôleur hôte". Donc, orientation principal: l'alimentation; Pas mal, mais à côté.
kb822603= Mise à jour extrait du SP2 pour XP, relatives principalement au partage des ressources alimentations; Mieux, mais tu n'as pas lu la page jusqu'au bout: L'IAD et "La gestion de périphériques à bande passante élevée", ne sont pas traités. Bête, c'est exactement la base de ton problème.
Soit une donnée qui doit passer du tampon d'un hub interne au tampon du hub externe, et retourner l'action voulu dans le même délai. Normalement d'un 2.0 à un 1.1, tu as une commande "WAIT" qui pallie le ralentissement des bus, là ton délai étant équivalent à zéro car tes hub tournent au même rythme, celui en aval déconnecte pour cause d'inactivitée. Ce n'est donc pas un problème matériel, mais mathématique.
peps
Messages postés
2216
Date d'inscription
vendredi 8 septembre 2000
Statut
Contributeur
Dernière intervention
26 juillet 2012
251
12 juil. 2004 à 13:39
12 juil. 2004 à 13:39
Bonjour,
Non ce problème est commun à beaucoup d'utilisateurs; C'est juste une question de recherches, pour le développement de la solution de débogage.
Je te conseille de t'adresser au site:
http://www.usb.org
Comme il existe des solutions pour les produits comme 3COM (modem), OLORAD(caméra numérique), etc...
NOTA: Je reconnais que mes explications ne sont pas très claires; Il faut concevoir le mode de transmissions des charges, et les délais palliés entre chaque opération durant un cycle d'horloge.
Une partie est compensée par la combinaison des matériaux composants chacun des éléments (l'agencement d'impuretés calibrées dans un circuit augmente la transmission sur un vecteur de 10 puissance 14, à 10 puissance 18). On a amélioré les délais de transmission de manière constante, mais là on se retrouve face à un problème similaire à celui posé par auparavant par la liaison entre le processeur et les mémoires RAM: par leur composition et leur conceptions ce sont des périphériques rapides, mais les bus de liaison étant moins rapide, il y avait rupture des cadences (le processeur se trouvait sans rien à traiter durant un cycle pouvant approcher 5 nanosecondes); on avait résolu le problème par un tampon anté-mémoire en avant du processeur qui régulant le flux de transmission empêchait le processeur de tourner à vide. Tu as donc vu qu'en mettant un intercalaire entre tes HUB tu avais pallié le problème de rupture (au détriment de la puissance). Retourne voir ton fournisseur matériel et expliques lui que ton PEABIRD n'est pas raccord avec le restant de ton matériel, il pourra soit t'aider à légérement overclocker ta CM (introduction de lignes particulières dans le fichier *.bin du bios, augmentation du voltage de certains composants, changement éventuel du câble de liaison entre les HUB par un de structure différente, etc...), ce qui palliera la déperdition et une partie du problème.
Non ce problème est commun à beaucoup d'utilisateurs; C'est juste une question de recherches, pour le développement de la solution de débogage.
Je te conseille de t'adresser au site:
http://www.usb.org
Comme il existe des solutions pour les produits comme 3COM (modem), OLORAD(caméra numérique), etc...
NOTA: Je reconnais que mes explications ne sont pas très claires; Il faut concevoir le mode de transmissions des charges, et les délais palliés entre chaque opération durant un cycle d'horloge.
Une partie est compensée par la combinaison des matériaux composants chacun des éléments (l'agencement d'impuretés calibrées dans un circuit augmente la transmission sur un vecteur de 10 puissance 14, à 10 puissance 18). On a amélioré les délais de transmission de manière constante, mais là on se retrouve face à un problème similaire à celui posé par auparavant par la liaison entre le processeur et les mémoires RAM: par leur composition et leur conceptions ce sont des périphériques rapides, mais les bus de liaison étant moins rapide, il y avait rupture des cadences (le processeur se trouvait sans rien à traiter durant un cycle pouvant approcher 5 nanosecondes); on avait résolu le problème par un tampon anté-mémoire en avant du processeur qui régulant le flux de transmission empêchait le processeur de tourner à vide. Tu as donc vu qu'en mettant un intercalaire entre tes HUB tu avais pallié le problème de rupture (au détriment de la puissance). Retourne voir ton fournisseur matériel et expliques lui que ton PEABIRD n'est pas raccord avec le restant de ton matériel, il pourra soit t'aider à légérement overclocker ta CM (introduction de lignes particulières dans le fichier *.bin du bios, augmentation du voltage de certains composants, changement éventuel du câble de liaison entre les HUB par un de structure différente, etc...), ce qui palliera la déperdition et une partie du problème.
Bonjour
Vraiment très intéressantes, ces informations.
J'ai aussi ce même problême de hub avec la même config que Fleclair: lorsque je branche ma souris sur le hub (usb 2.0) cela provoque, au moindre mouvement de la souris, une montée du régime du processeur jusqu'à 80%, ce qui n'est pas le cas lorsque la souris est branchée direct sur l'usb du PC.
Y a t il une solution?
Vraiment très intéressantes, ces informations.
J'ai aussi ce même problême de hub avec la même config que Fleclair: lorsque je branche ma souris sur le hub (usb 2.0) cela provoque, au moindre mouvement de la souris, une montée du régime du processeur jusqu'à 80%, ce qui n'est pas le cas lorsque la souris est branchée direct sur l'usb du PC.
Y a t il une solution?
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
peps
Messages postés
2216
Date d'inscription
vendredi 8 septembre 2000
Statut
Contributeur
Dernière intervention
26 juillet 2012
251
30 juil. 2004 à 17:05
30 juil. 2004 à 17:05
Bonjour,
pour MARS:
Un peu d'histoire: Le gestionnaire de l'interface graphique du pointeur (on considére en fait un point localisé sur une grille, la flèche c'est de l'habillage; Et les clics gauche et droit, le bouton central ou molette et autres boutons annexes étant assujetis au choix de l'utilisateur), fonctionne sur une grille en avant-plan de l'affichage (du 0-0 en haut à gauche au nx-ny en bas à droite). Ce gestionnaire fût étudier et mis au point par un des chercheurs des bureaux d'études IBM (détail amusant, à l'époque la direction n'avait pas considéré ce travail technique comme intéressant; comme beaucoup d'autre novations encore en usage).
Avec l'évolution des techniques, ce programme fût intégré au BIOS, en mode standard. C'est ainsi que sur la majorité des 486 on voit toujours ce message "LOAD MOUSE DRIVE FAIL" "no device mouse found, press F1 to skip or DEL to solve the problem".
C'est donc ce programme standard qui déborde ton processeur, lorsque ta souris est connecté directement à la carte-mère, l'adresse étant définie, la gestion reste simple; Lorsque tu mets un HUB externe 2.0 entre ta souris et ta CM, le gestionnaire paume l'adresse et donc augmente les sollicitations sur le processeur pour maintenir la liaison (heureusement c'est un programme hyper-léger 1k environ pour le fichier *.com de liaison et 4k pour le mouse.sys+ quelques lignes sur le I/O). Imagines que tu fasses un test plus convaincant avec une imprimante, ou un routeur, il faudrait que tu trouves un palliatif délai (wait responding true or false) pour que ton appareil HUB s'intégre. Bonne chance des centaines de personnes bossent déjà sur le problème.
pour MARS:
Un peu d'histoire: Le gestionnaire de l'interface graphique du pointeur (on considére en fait un point localisé sur une grille, la flèche c'est de l'habillage; Et les clics gauche et droit, le bouton central ou molette et autres boutons annexes étant assujetis au choix de l'utilisateur), fonctionne sur une grille en avant-plan de l'affichage (du 0-0 en haut à gauche au nx-ny en bas à droite). Ce gestionnaire fût étudier et mis au point par un des chercheurs des bureaux d'études IBM (détail amusant, à l'époque la direction n'avait pas considéré ce travail technique comme intéressant; comme beaucoup d'autre novations encore en usage).
Avec l'évolution des techniques, ce programme fût intégré au BIOS, en mode standard. C'est ainsi que sur la majorité des 486 on voit toujours ce message "LOAD MOUSE DRIVE FAIL" "no device mouse found, press F1 to skip or DEL to solve the problem".
C'est donc ce programme standard qui déborde ton processeur, lorsque ta souris est connecté directement à la carte-mère, l'adresse étant définie, la gestion reste simple; Lorsque tu mets un HUB externe 2.0 entre ta souris et ta CM, le gestionnaire paume l'adresse et donc augmente les sollicitations sur le processeur pour maintenir la liaison (heureusement c'est un programme hyper-léger 1k environ pour le fichier *.com de liaison et 4k pour le mouse.sys+ quelques lignes sur le I/O). Imagines que tu fasses un test plus convaincant avec une imprimante, ou un routeur, il faudrait que tu trouves un palliatif délai (wait responding true or false) pour que ton appareil HUB s'intégre. Bonne chance des centaines de personnes bossent déjà sur le problème.
3 juil. 2004 à 20:29
- Les ports intégrés à la CM ???? qu'est ce ???
- USB 1.1 et USB2, c'est différent ?
Je pensais qu'il n'existait que USB 1 et USB2 (ou USB1.1)
J'ai installé winXP SP1a avec le dernier correctif des USB2, càd le Q810400_WXP_SP2_x86_FRA qui corrige le pilote hubusb.sys
J'ai également installé le correctif "WindowsXP-KB822603-x86-FRA" qui corrige des problèmes d'USB2.
Par ailleurs, le hub USB Peabird autoalimenté 4 ports USB2 n'a pas de driver, il est vendu sans et utilise le pilote de windows XP.