Juste une question:
Sur un switch ethernet 10/100 , comme fait il pour convertir les trames 100
en 10.
Au début, il doit y avoir un ptit buffer, mais potentiellement, le temps
qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames a 100,
donc le buffer pourrait se retrouver saturé rapidement. Envoie il des
messages de controle de flux a la source?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
trallala
le switch ne fait que "switcher" participants,
donc si l´un est a 10, l`autre sera a 10 aussi
les cartes 100 possedent le mode 10 ( backward compatibility )
les vieilles cartes 10 n'ont que le mode 10
y a nulle part de buffer
bm <bm at netvalor.com> schrieb in im Newsbeitrag: 3fc0aa2b$0$26810$
Bonjour
Juste une question: Sur un switch ethernet 10/100 , comme fait il pour convertir les trames 100
en 10. Au début, il doit y avoir un ptit buffer, mais potentiellement, le temps qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames a 100, donc le buffer pourrait se retrouver saturé rapidement. Envoie il des messages de controle de flux a la source?
le switch ne fait que "switcher" participants,
donc si l´un est a 10, l`autre sera a 10 aussi
les cartes 100 possedent le mode 10 ( backward compatibility )
les vieilles cartes 10 n'ont que le mode 10
y a nulle part de buffer
bm <bm at netvalor.com> schrieb in im Newsbeitrag:
3fc0aa2b$0$26810$636a55ce@news.free.fr...
Bonjour
Juste une question:
Sur un switch ethernet 10/100 , comme fait il pour convertir les trames
100
en 10.
Au début, il doit y avoir un ptit buffer, mais potentiellement, le temps
qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames a 100,
donc le buffer pourrait se retrouver saturé rapidement. Envoie il des
messages de controle de flux a la source?
les cartes 100 possedent le mode 10 ( backward compatibility )
les vieilles cartes 10 n'ont que le mode 10
y a nulle part de buffer
bm <bm at netvalor.com> schrieb in im Newsbeitrag: 3fc0aa2b$0$26810$
Bonjour
Juste une question: Sur un switch ethernet 10/100 , comme fait il pour convertir les trames 100
en 10. Au début, il doit y avoir un ptit buffer, mais potentiellement, le temps qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames a 100, donc le buffer pourrait se retrouver saturé rapidement. Envoie il des messages de controle de flux a la source?
Annie D.
trallala wrote:
le switch ne fait que "switcher" participants,
Non. Il commute les trames.
donc si l´un est a 10, l`autre sera a 10 aussi
Non. Chacun a son débit propre.
les cartes 100 possedent le mode 10 ( backward compatibility )
Une interface 10/100 configurée en 100 ne fonctionne pas en 10.
les vieilles cartes 10 n'ont que le mode 10
Enfin. On ne peut pas se tromper tout le temps.
y a nulle part de buffer
Si.
bm <bm at netvalor.com> schrieb :
Sur un switch ethernet 10/100 , comme fait il pour convertir les trames 100 en 10.
Tout bêtement : il reçoit la trame dans un format, la stocke et la retransmet ensuite dans l'autre. C'est la méthode "store and forward".
Au début, il doit y avoir un ptit buffer,
En effet, et pas forcément si petit que ça selon les performances du switch. Je n'ai aucune idée de la taille.
mais potentiellement, le temps qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames a 100, donc le buffer pourrait se retrouver saturé rapidement. Envoie il des messages de controle de flux a la source?
Il y a plusieurs méthode possibles de contrôle de flux. Effectivement au niveau ethernet, et/ou au niveau des couches réseau supérieures. Par exemple, le système d'acquittement du protocole TCP/IP réalise de fait un contrôle de flux.
trallala wrote:
le switch ne fait que "switcher" participants,
Non. Il commute les trames.
donc si l´un est a 10, l`autre sera a 10 aussi
Non. Chacun a son débit propre.
les cartes 100 possedent le mode 10 ( backward compatibility )
Une interface 10/100 configurée en 100 ne fonctionne pas en 10.
les vieilles cartes 10 n'ont que le mode 10
Enfin. On ne peut pas se tromper tout le temps.
y a nulle part de buffer
Si.
bm <bm at netvalor.com> schrieb :
Sur un switch ethernet 10/100 , comme fait il pour convertir les trames
100 en 10.
Tout bêtement : il reçoit la trame dans un format, la stocke et la
retransmet ensuite dans l'autre. C'est la méthode "store and forward".
Au début, il doit y avoir un ptit buffer,
En effet, et pas forcément si petit que ça selon les performances du
switch. Je n'ai aucune idée de la taille.
mais potentiellement, le temps
qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames a 100,
donc le buffer pourrait se retrouver saturé rapidement. Envoie il des
messages de controle de flux a la source?
Il y a plusieurs méthode possibles de contrôle de flux. Effectivement au
niveau ethernet, et/ou au niveau des couches réseau supérieures. Par
exemple, le système d'acquittement du protocole TCP/IP réalise de fait
un contrôle de flux.
les cartes 100 possedent le mode 10 ( backward compatibility )
Une interface 10/100 configurée en 100 ne fonctionne pas en 10.
les vieilles cartes 10 n'ont que le mode 10
Enfin. On ne peut pas se tromper tout le temps.
y a nulle part de buffer
Si.
bm <bm at netvalor.com> schrieb :
Sur un switch ethernet 10/100 , comme fait il pour convertir les trames 100 en 10.
Tout bêtement : il reçoit la trame dans un format, la stocke et la retransmet ensuite dans l'autre. C'est la méthode "store and forward".
Au début, il doit y avoir un ptit buffer,
En effet, et pas forcément si petit que ça selon les performances du switch. Je n'ai aucune idée de la taille.
mais potentiellement, le temps qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames a 100, donc le buffer pourrait se retrouver saturé rapidement. Envoie il des messages de controle de flux a la source?
Il y a plusieurs méthode possibles de contrôle de flux. Effectivement au niveau ethernet, et/ou au niveau des couches réseau supérieures. Par exemple, le système d'acquittement du protocole TCP/IP réalise de fait un contrôle de flux.
Zythum
En effet, et pas forcément si petit que ça selon les performances du switch. Je n'ai aucune idée de la taille.
environ 256 Ko pour un switch basique. ça peut aller jusqu'à au moins 16 Mo pour un switch 24 ports 10/100 manageable de milieu de gamme.
mais potentiellement, le temps qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames a 100, donc le buffer pourrait se retrouver saturé rapidement. Envoie il des messages de controle de flux a la source?
Il y a plusieurs méthode possibles de contrôle de flux. Effectivement au niveau ethernet, et/ou au niveau des couches réseau supérieures. Par exemple, le système d'acquittement du protocole TCP/IP réalise de fait un contrôle de flux.
Pour compléter un peu : Si le controle de flux au niveau ethernet n'est pas activé, lorsque le buffer est plein, les trames en surplues sont tout simplement supprimées par le switch. A charge aux couches supérieures (TCP par exemple) de voir qu'il y a eu un problème. Bien sur c'est assez pénalisant comme méthode en termes de performance.
Si le controle de flux au niveau ethernet est actif, il se fait selon deux méthodes : - le port est en half-duplex, comme à l'origine le controle de flux n'existe par en ethernet (puisque une seule machine occupe le média et que tout le monde cause à la même vitesse) le switch se contente de simuler des collisions sur ce port => évidemment le PC trop bavard se calme tout de suite. - le port est en full-duplex, alors c'est la norme IEEE 802.3x qui prend le relai, mais comme je ne l'ai jamais lu je ne peux rien en dire de plus.
-- Zythum
En effet, et pas forcément si petit que ça selon les performances du
switch. Je n'ai aucune idée de la taille.
environ 256 Ko pour un switch basique.
ça peut aller jusqu'à au moins 16 Mo pour un switch 24 ports 10/100
manageable de milieu de gamme.
mais potentiellement, le temps
qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames
a 100, donc le buffer pourrait se retrouver saturé rapidement.
Envoie il des messages de controle de flux a la source?
Il y a plusieurs méthode possibles de contrôle de flux. Effectivement
au niveau ethernet, et/ou au niveau des couches réseau supérieures.
Par exemple, le système d'acquittement du protocole TCP/IP réalise de
fait un contrôle de flux.
Pour compléter un peu :
Si le controle de flux au niveau ethernet n'est pas activé, lorsque le
buffer est plein, les trames en surplues sont tout simplement supprimées par
le switch. A charge aux couches supérieures (TCP par exemple) de voir qu'il
y a eu un problème. Bien sur c'est assez pénalisant comme méthode en termes
de performance.
Si le controle de flux au niveau ethernet est actif, il se fait selon deux
méthodes :
- le port est en half-duplex, comme à l'origine le controle de flux n'existe
par en ethernet (puisque une seule machine occupe le média et que tout le
monde cause à la même vitesse) le switch se contente de simuler des
collisions sur ce port => évidemment le PC trop bavard se calme tout de
suite.
- le port est en full-duplex, alors c'est la norme IEEE 802.3x qui prend le
relai, mais comme je ne l'ai jamais lu je ne peux rien en dire de plus.
En effet, et pas forcément si petit que ça selon les performances du switch. Je n'ai aucune idée de la taille.
environ 256 Ko pour un switch basique. ça peut aller jusqu'à au moins 16 Mo pour un switch 24 ports 10/100 manageable de milieu de gamme.
mais potentiellement, le temps qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames a 100, donc le buffer pourrait se retrouver saturé rapidement. Envoie il des messages de controle de flux a la source?
Il y a plusieurs méthode possibles de contrôle de flux. Effectivement au niveau ethernet, et/ou au niveau des couches réseau supérieures. Par exemple, le système d'acquittement du protocole TCP/IP réalise de fait un contrôle de flux.
Pour compléter un peu : Si le controle de flux au niveau ethernet n'est pas activé, lorsque le buffer est plein, les trames en surplues sont tout simplement supprimées par le switch. A charge aux couches supérieures (TCP par exemple) de voir qu'il y a eu un problème. Bien sur c'est assez pénalisant comme méthode en termes de performance.
Si le controle de flux au niveau ethernet est actif, il se fait selon deux méthodes : - le port est en half-duplex, comme à l'origine le controle de flux n'existe par en ethernet (puisque une seule machine occupe le média et que tout le monde cause à la même vitesse) le switch se contente de simuler des collisions sur ce port => évidemment le PC trop bavard se calme tout de suite. - le port est en full-duplex, alors c'est la norme IEEE 802.3x qui prend le relai, mais comme je ne l'ai jamais lu je ne peux rien en dire de plus.
-- Zythum
bm
merci pour vos réponses :-)
"Zythum" a écrit dans le message de news:3fc11d41$0$27015$
En effet, et pas forcément si petit que ça selon les performances du switch. Je n'ai aucune idée de la taille.
environ 256 Ko pour un switch basique. ça peut aller jusqu'à au moins 16 Mo pour un switch 24 ports 10/100 manageable de milieu de gamme.
mais potentiellement, le temps qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames a 100, donc le buffer pourrait se retrouver saturé rapidement. Envoie il des messages de controle de flux a la source?
Il y a plusieurs méthode possibles de contrôle de flux. Effectivement au niveau ethernet, et/ou au niveau des couches réseau supérieures. Par exemple, le système d'acquittement du protocole TCP/IP réalise de fait un contrôle de flux.
Pour compléter un peu : Si le controle de flux au niveau ethernet n'est pas activé, lorsque le buffer est plein, les trames en surplues sont tout simplement supprimées par
le switch. A charge aux couches supérieures (TCP par exemple) de voir qu'il
y a eu un problème. Bien sur c'est assez pénalisant comme méthode en termes
de performance.
Si le controle de flux au niveau ethernet est actif, il se fait selon deux méthodes : - le port est en half-duplex, comme à l'origine le controle de flux n'existe
par en ethernet (puisque une seule machine occupe le média et que tout le monde cause à la même vitesse) le switch se contente de simuler des collisions sur ce port => évidemment le PC trop bavard se calme tout de suite. - le port est en full-duplex, alors c'est la norme IEEE 802.3x qui prend le
relai, mais comme je ne l'ai jamais lu je ne peux rien en dire de plus.
-- Zythum
merci pour vos réponses :-)
"Zythum" <xx@x.x> a écrit dans le message de
news:3fc11d41$0$27015$626a54ce@news.free.fr...
En effet, et pas forcément si petit que ça selon les performances du
switch. Je n'ai aucune idée de la taille.
environ 256 Ko pour un switch basique.
ça peut aller jusqu'à au moins 16 Mo pour un switch 24 ports 10/100
manageable de milieu de gamme.
mais potentiellement, le temps
qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames
a 100, donc le buffer pourrait se retrouver saturé rapidement.
Envoie il des messages de controle de flux a la source?
Il y a plusieurs méthode possibles de contrôle de flux. Effectivement
au niveau ethernet, et/ou au niveau des couches réseau supérieures.
Par exemple, le système d'acquittement du protocole TCP/IP réalise de
fait un contrôle de flux.
Pour compléter un peu :
Si le controle de flux au niveau ethernet n'est pas activé, lorsque le
buffer est plein, les trames en surplues sont tout simplement supprimées
par
le switch. A charge aux couches supérieures (TCP par exemple) de voir
qu'il
y a eu un problème. Bien sur c'est assez pénalisant comme méthode en
termes
de performance.
Si le controle de flux au niveau ethernet est actif, il se fait selon deux
méthodes :
- le port est en half-duplex, comme à l'origine le controle de flux
n'existe
par en ethernet (puisque une seule machine occupe le média et que tout le
monde cause à la même vitesse) le switch se contente de simuler des
collisions sur ce port => évidemment le PC trop bavard se calme tout de
suite.
- le port est en full-duplex, alors c'est la norme IEEE 802.3x qui prend
le
relai, mais comme je ne l'ai jamais lu je ne peux rien en dire de plus.
"Zythum" a écrit dans le message de news:3fc11d41$0$27015$
En effet, et pas forcément si petit que ça selon les performances du switch. Je n'ai aucune idée de la taille.
environ 256 Ko pour un switch basique. ça peut aller jusqu'à au moins 16 Mo pour un switch 24 ports 10/100 manageable de milieu de gamme.
mais potentiellement, le temps qu'il envoie la trame à 10, il pourrait avoir recu plusieurs trames a 100, donc le buffer pourrait se retrouver saturé rapidement. Envoie il des messages de controle de flux a la source?
Il y a plusieurs méthode possibles de contrôle de flux. Effectivement au niveau ethernet, et/ou au niveau des couches réseau supérieures. Par exemple, le système d'acquittement du protocole TCP/IP réalise de fait un contrôle de flux.
Pour compléter un peu : Si le controle de flux au niveau ethernet n'est pas activé, lorsque le buffer est plein, les trames en surplues sont tout simplement supprimées par
le switch. A charge aux couches supérieures (TCP par exemple) de voir qu'il
y a eu un problème. Bien sur c'est assez pénalisant comme méthode en termes
de performance.
Si le controle de flux au niveau ethernet est actif, il se fait selon deux méthodes : - le port est en half-duplex, comme à l'origine le controle de flux n'existe
par en ethernet (puisque une seule machine occupe le média et que tout le monde cause à la même vitesse) le switch se contente de simuler des collisions sur ce port => évidemment le PC trop bavard se calme tout de suite. - le port est en full-duplex, alors c'est la norme IEEE 802.3x qui prend le
relai, mais comme je ne l'ai jamais lu je ne peux rien en dire de plus.
