Recherche
Archives
Informations
13 visites ce jour / 15340 - adresse IP : 23.20.248.132 - système : - navigateur :
Téléchargements

Articles avec le tag ‘hub’

switch En fait, cette solution est un retour à une fonctionnalité qui existait il y a 10 ans sur les switchs. Elle présente l’avantage de proposer un temps de traversée identique quelque soit la taille de la trame à l’inverse de la commutation “Store & Forward” qui doit stocker la trame en totalité avant de la rediriger. Cette ancienne solution est mise au gout du jour en intégrant la gestion de la qualité de service (802.1Q / 802.1p)et donc des VLANs.

L’inconvénient majeur de cette solution est de ne proposer qu’une solution mono-débit de bout en bout (ici du 100Mb/s) car il est impossible avec cette solution de passer à un débit moindre (10Mbit/s) ou plus important (gigabit). Or le temps de latence du switch “store & forward” annoncé comme problématique en 100Mb/s (ici de 120µs) est divisé par 10 en gigabit minimisant ainsi l’impact du transport sur le réseau automatisme et garantissant l’interopérabilité entre switchs de différents constructeurs respectant le standard. Par ailleurs, en intégrant le standard IEEE1588, le PTP : Precision Time Protocol, le temps de parcours de tout le réseau peut être mesuré précisément de bout en bout et permettre ainsi de déterminer les critères Temps Réel du réseau traversé.

Pour diminuer encore plus le temps de traversé du réseau, on peut aussi remplacer les switchs par des hubs (répéteurs) 100Mb/s (quitte a les “bidouiller” un peu pour éviter les collisions que la méthode CSMA/CD classique amène sur ce type de produit – ce que n’hésite pas à proposer certains constructeurs automatismes). En résumé, le choix sera de savoir si l’on souhaite une solution ouverte et pérenne ou une solution propriétaire… 

Store and forward, cut-through Ethernet switching

The performance of switching technology is greatly enhanced by use of cut-through switching technology rather than store-and-forward technology. (See figure 1.)
Neither will guarantee determinism, however, making both insufficient for many automation applications. Protocol prioritization for IEEE 802.1q also is ineffective because automation protocols compete with other protocols of the same and higher priority. The delays that can result are unacceptable for automation.

Two delay mechanisms are:

– Delays in the input port: If an input port’s queue (memory) is saturated with traffic from other protocols of the same or higher priority than the automation protocols, then the automation messages are delayed. (See figure 2.) This leads to unpredictable delays for automation protocols.

Lire la suite de cette entrée »