A voir également:
- Collision switch
- Logiciel switch - Télécharger - Conversion & Extraction
- Samsung switch pc - Télécharger - Divers Bureautique
- Switch qwerty azerty - Guide
- Switch fédérateur - Forum câblage
- Assassin's creed black flag switch pas de voix - Forum Nintendo Switch
7 réponses
les collisions sont tous a fait normal dans un reseau ethernet, car les machine envoie des message en méme temp, la il ya collision alors les machinent attendent un temp aléatoire pour la retrensmission des messages,$
la solutions utilisé est de mettre des switch ou des routeurs qui découppe les lan en plusieurs domaines de collision.
la solutions utilisé est de mettre des switch ou des routeurs qui découppe les lan en plusieurs domaines de collision.
ouais, il y a déja des hubs, et c'est justement grâce a eux que je m'aperçoit qu'il y a collision car ils clignote orange et sur l'un d'eux, il y a un voyant rouge "collision" qui s'allume...
je sais qu'il y a toujours des collisions sur un réseau ethernet mais là, il y en a trop et ça bloque assez gravement le réseau...
merci quand même, si t'as une autre idée...je dois absolumennt faiire quelque chose, ça peut venir du cable mais de quoi encore...
je sais qu'il y a toujours des collisions sur un réseau ethernet mais là, il y en a trop et ça bloque assez gravement le réseau...
merci quand même, si t'as une autre idée...je dois absolumennt faiire quelque chose, ça peut venir du cable mais de quoi encore...
Eaulive
Messages postés
27038
Date d'inscription
jeudi 18 avril 2002
Statut
Modérateur
Dernière intervention
23 juin 2015
289
18 oct. 2002 à 22:37
18 oct. 2002 à 22:37
Comme te l'a dit Lyes, tu pourrais commencer par mettre un switch au lieu d'un hub car le switch isole les domaines de collision.
Tu as beaucoup de pc's?
Eaulive... Rien n'est vraiment cuit
tant que tout n'est pas entièrement brûlé.--T.S.C--
Tu as beaucoup de pc's?
Eaulive... Rien n'est vraiment cuit
tant que tout n'est pas entièrement brûlé.--T.S.C--
j'ai 25 Pcs....mettre des switch à la place des hubs n'est pas la seule solution quand même, si....mais de quoi peut venir cette collision svp....merci pour vos réponses
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Eaulive
Messages postés
27038
Date d'inscription
jeudi 18 avril 2002
Statut
Modérateur
Dernière intervention
23 juin 2015
289
19 oct. 2002 à 17:47
19 oct. 2002 à 17:47
Ouais, j'ai pas vraiment de super connaissances en réseau mais si brupala (entre autres) se pointe il pourra te répondre mieux que moi.
Ce que j'en pense: mettre des switchs va améliorer ton problème de collisions et va accélérer ton réseau, l'étape suivante serait de mettre un (des?) routeurs afin de créer plusieurs sous-réseaux ou groupes de travail, mais là je m'avance un peu dans l'inconnu car je n'ai jamais expérimenté au-delà de 8 pc tu vois ;-)
Bonne chance et remonte le post de temps en temps au cas ou d'autres calés passeraient ;-)
Eaulive... Rien n'est vraiment cuit
tant que tout n'est pas entièrement brûlé.--T.S.C--
Ce que j'en pense: mettre des switchs va améliorer ton problème de collisions et va accélérer ton réseau, l'étape suivante serait de mettre un (des?) routeurs afin de créer plusieurs sous-réseaux ou groupes de travail, mais là je m'avance un peu dans l'inconnu car je n'ai jamais expérimenté au-delà de 8 pc tu vois ;-)
Bonne chance et remonte le post de temps en temps au cas ou d'autres calés passeraient ;-)
Eaulive... Rien n'est vraiment cuit
tant que tout n'est pas entièrement brûlé.--T.S.C--
brupala
Messages postés
109458
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
26 avril 2024
13 626
19 oct. 2002 à 23:56
19 oct. 2002 à 23:56
salut,
Merci olive ;-)
Bon , c'est pas normal d'avoir BEAUCOUP de collisions (genre voyant allumé presque en permanence).
Les collisions sont prévues et gérées par le réseau ethernet, mais si il y en a beaucoup, c'est que:
1_Le réseau est complètement saturé (plus de 40 % de charge).
2_ Une carte réseau defectueuse qui ne détecte pas l'émission des autres ou qui émet en permanence va provoquer une cascade de collisions.
3_ un équipement qui réémet (pour un problème de routege) systématiquement les trames qu'il recoit.
donc, il faut chercher dans tous ces sens là.
et ... Voili Voilou Voila !
Merci olive ;-)
Bon , c'est pas normal d'avoir BEAUCOUP de collisions (genre voyant allumé presque en permanence).
Les collisions sont prévues et gérées par le réseau ethernet, mais si il y en a beaucoup, c'est que:
1_Le réseau est complètement saturé (plus de 40 % de charge).
2_ Une carte réseau defectueuse qui ne détecte pas l'émission des autres ou qui émet en permanence va provoquer une cascade de collisions.
3_ un équipement qui réémet (pour un problème de routege) systématiquement les trames qu'il recoit.
donc, il faut chercher dans tous ces sens là.
et ... Voili Voilou Voila !
brupala
Messages postés
109458
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
26 avril 2024
13 626
>
Ludo
20 oct. 2002 à 23:53
20 oct. 2002 à 23:53
p'tain ce m&m ...
bon,
non, un hub ne réémetra jamais rien, il se contente de transmettre , diffuser sur tout ce qui lui est connecté,.
quand je dis réemetre commeça c'est une trame que la machine (plutot un routeur) recoit et qui est destinée à un autre (pour le niveau 3), à ce moment là, il la réemet sur le port où il l'a reçue , ce qui peut (devrait pas ) provoquer des collisions .
Je dis ça parce que je l'ai vu une fois, mais c'était un bug.
et ... Voili Voilou Voila !
bon,
non, un hub ne réémetra jamais rien, il se contente de transmettre , diffuser sur tout ce qui lui est connecté,.
quand je dis réemetre commeça c'est une trame que la machine (plutot un routeur) recoit et qui est destinée à un autre (pour le niveau 3), à ce moment là, il la réemet sur le port où il l'a reçue , ce qui peut (devrait pas ) provoquer des collisions .
Je dis ça parce que je l'ai vu une fois, mais c'était un bug.
et ... Voili Voilou Voila !
M&M
Messages postés
5038
Date d'inscription
dimanche 11 août 2002
Statut
Contributeur
Dernière intervention
3 décembre 2009
667
20 oct. 2002 à 06:06
20 oct. 2002 à 06:06
Bonsoir,
pour la topologie Ethernet, il y a toujours les mêmes règles qui jouent. Une carte émet un préambule qui se propage de bout en bout. Tous ceux qui l'entendent sont priés de postposer leur envoi. Si une station émet d'un côté pour entendre un peu après qu'une autre avait déjà commencé, il y a superposition des porteuses de 10 ou 100MHz avec une tension dépassant un seuil (sur le câble coax deux fois deux volts moins l'atténuation du câble de 4 ou 5 db, cela détermine les pertes admissibles et de là la longueur maximale de 185 mètres). En cas de collision, les cartes continuent d'émettre un petit peu pour bien signifier à l'autre, même à l'extrémité du réseau (dont l'envergure maximale avait été évaluée à 2Km pour le campus de Stanford à la création de la norme) que c'est peine perdue et qu'il faut se taire. Tous ceux qui étaient impliqués dans la collision seront retardés d'un délai aléatoire par pas exponentiel en fonction du nombre de collisions déjà subies pour accéder au câble. Donc une carte attendra 1 ou 2 temps, une autre 1,2,3 ou 4 temps et à la troisième collision de 1 à 8. etc... À la longue, il y a bien une carte qui émet pendant que toutes les autres attendent leur temps aléatoire. et ainsi, le conflit d'accès est résolu, avec comme corollaire qu'on sait quand un PC demande à sa carte de transmettre, on ne sait pas exactement à quel moment le paquet aura été valablement transmis.
S'il y a un bruit sur la ligne en plein milieu du paquet, le code CRC qui termine l'envoi sera vérifié chez le destinataire et déclaré non valide. C'est la couche de protocole qui devra décider de le réexpédier. Puisque dans ce cas l'expéditeur ne s'en doute pas. Ceci ralentira considérablement le transport.
Donc, pour que cela marche bien: les câbles ne doivent pas dépasser la porté élémentaire: en yellow cable (coax de 11 mm) 500 m, en coax fin (5mm) 185 mètres, en UTP 100 mètres. À des fréquences plus élevées, plus court selon la qualité du câble. mais il y a aussi une limite d'envergure pour le réseau avec hubs en cascade: de 2km ou quatre sauts je crois. Exemple: deux hubs avec une fibre optique de 2km entre les deux, cela marche. C'est basé sur le temps de propagation (proche de la vitesse de la lumière) par rapport à la durée du préambule (période d'émission d'une porteuse sans données destinée à lever les conflits d'accès).
Or si on met des bridges ou des routeurs, les paquets sont stockés et réémis, ce qui change la donne. Le boîtier accepte le paquet et le prend en charge avec sa table de destinataires situés à gauche et à droite du pont filtrant. Il se charge alors de le réémettre avec, lui aussi le risque de collision sur son tronçon. Mais le saucissonnage du LAN par segment cloisonne le trafic et permet d'augmenter le débit global et le temps moyen pour délivrer les paquets qui, sinon subirait des retards par le mécanisme d'attente pseudo-aléatoire de résolution des collisions.
Il faut pour cela que les utilisateurs d'un service voient leur serveur sur ce même tronçon: la compta près des gens de la compta, le développement du côté du serveur développement. Il faut que le trafic préférentiel ne doivent pas passer au travers du bridge.
Il faut bien penser à cela malgré le fait que le réseau n'est plus un bus prolongé aux extrémités mais des étoiles aboutissant à un hub, ces hubs étant interconnectés souvent par étage.
les appareils modernes indiquent un défaut sur une ligne, due à l'absence de signal, ou due à une carte qui émet en permanence. Dans ce cas, le boîtier isole cette entrée pour éviter de tuer le débit du câble. Ce problème ne doit absolument pas se propager.
Sur les serveurs novell, on a un outil de diagnostic pour toutes les cartes du serveur: donnant le nombre de paquets transportés, le nombre de bytes transportés, le nombre de collisions détectées et le nombre d'erreurs de CRC.
Ces erreurs de CRC peuvent venir d'influences extérieures: bruits d'impulsion due à la diaphonie avec d'autres services dans des câbles de mauvaise qualité. J'arrête ici.
:,§_ ç _
(@)=(@)
pour la topologie Ethernet, il y a toujours les mêmes règles qui jouent. Une carte émet un préambule qui se propage de bout en bout. Tous ceux qui l'entendent sont priés de postposer leur envoi. Si une station émet d'un côté pour entendre un peu après qu'une autre avait déjà commencé, il y a superposition des porteuses de 10 ou 100MHz avec une tension dépassant un seuil (sur le câble coax deux fois deux volts moins l'atténuation du câble de 4 ou 5 db, cela détermine les pertes admissibles et de là la longueur maximale de 185 mètres). En cas de collision, les cartes continuent d'émettre un petit peu pour bien signifier à l'autre, même à l'extrémité du réseau (dont l'envergure maximale avait été évaluée à 2Km pour le campus de Stanford à la création de la norme) que c'est peine perdue et qu'il faut se taire. Tous ceux qui étaient impliqués dans la collision seront retardés d'un délai aléatoire par pas exponentiel en fonction du nombre de collisions déjà subies pour accéder au câble. Donc une carte attendra 1 ou 2 temps, une autre 1,2,3 ou 4 temps et à la troisième collision de 1 à 8. etc... À la longue, il y a bien une carte qui émet pendant que toutes les autres attendent leur temps aléatoire. et ainsi, le conflit d'accès est résolu, avec comme corollaire qu'on sait quand un PC demande à sa carte de transmettre, on ne sait pas exactement à quel moment le paquet aura été valablement transmis.
S'il y a un bruit sur la ligne en plein milieu du paquet, le code CRC qui termine l'envoi sera vérifié chez le destinataire et déclaré non valide. C'est la couche de protocole qui devra décider de le réexpédier. Puisque dans ce cas l'expéditeur ne s'en doute pas. Ceci ralentira considérablement le transport.
Donc, pour que cela marche bien: les câbles ne doivent pas dépasser la porté élémentaire: en yellow cable (coax de 11 mm) 500 m, en coax fin (5mm) 185 mètres, en UTP 100 mètres. À des fréquences plus élevées, plus court selon la qualité du câble. mais il y a aussi une limite d'envergure pour le réseau avec hubs en cascade: de 2km ou quatre sauts je crois. Exemple: deux hubs avec une fibre optique de 2km entre les deux, cela marche. C'est basé sur le temps de propagation (proche de la vitesse de la lumière) par rapport à la durée du préambule (période d'émission d'une porteuse sans données destinée à lever les conflits d'accès).
Or si on met des bridges ou des routeurs, les paquets sont stockés et réémis, ce qui change la donne. Le boîtier accepte le paquet et le prend en charge avec sa table de destinataires situés à gauche et à droite du pont filtrant. Il se charge alors de le réémettre avec, lui aussi le risque de collision sur son tronçon. Mais le saucissonnage du LAN par segment cloisonne le trafic et permet d'augmenter le débit global et le temps moyen pour délivrer les paquets qui, sinon subirait des retards par le mécanisme d'attente pseudo-aléatoire de résolution des collisions.
Il faut pour cela que les utilisateurs d'un service voient leur serveur sur ce même tronçon: la compta près des gens de la compta, le développement du côté du serveur développement. Il faut que le trafic préférentiel ne doivent pas passer au travers du bridge.
Il faut bien penser à cela malgré le fait que le réseau n'est plus un bus prolongé aux extrémités mais des étoiles aboutissant à un hub, ces hubs étant interconnectés souvent par étage.
les appareils modernes indiquent un défaut sur une ligne, due à l'absence de signal, ou due à une carte qui émet en permanence. Dans ce cas, le boîtier isole cette entrée pour éviter de tuer le débit du câble. Ce problème ne doit absolument pas se propager.
Sur les serveurs novell, on a un outil de diagnostic pour toutes les cartes du serveur: donnant le nombre de paquets transportés, le nombre de bytes transportés, le nombre de collisions détectées et le nombre d'erreurs de CRC.
Ces erreurs de CRC peuvent venir d'influences extérieures: bruits d'impulsion due à la diaphonie avec d'autres services dans des câbles de mauvaise qualité. J'arrête ici.
:,§_ ç _
(@)=(@)
