Auteur Sujet: Ethernet omniprésent : quel surcout pour l'overhead?  (Lu 25382 fois)

0 Membres et 1 Invité sur ce sujet

  • Invité
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #36 le: 13 août 2016 à 10:00:33 »
On se demande bien pourquoi ce qui marche en xDSL ne marche pas en yDSL.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 602
  • La Madeleine (59)
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #37 le: 13 août 2016 à 13:56:22 »
Tu parles de datagram ethernet, corrector, du coup je viens d'aller revoir sur wikipedia : https://en.wikipedia.org/wiki/Ethernet_frame

Si je compte bien, cela fait 38B minimum d'overhead par paquet (+4 si utilisation de vlan)

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 479
  • Malissard (26)
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #38 le: 13 août 2016 à 14:32:51 »
Tu comptes au niveau 1 ou 2 ? C'est toujours l'éternel débat, un peu comme la taille minimale de 64 octets.

  • Invité
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #39 le: 13 août 2016 à 21:38:59 »
La question portait sur le SUR-coût lié à l'Ethernet. On compte ce que le choix de Ethernet ajoute. Si le préfixe sert éviter des collisions, et que le padding permet de garantir qu'on les détecte, et qu'il faut détecter les collisions, on ne le compte pas puisqu'il faudra bien éviter/détecter les collisions d'une façon ou d'une autre.

Très, très élèmentaire.

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 6 213
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #40 le: 13 août 2016 à 22:11:20 »
La question portait sur le SUR-coût lié à l'Ethernet. On compte ce que le choix de Ethernet ajoute. Si le préfixe sert éviter des collisions, et que le padding permet de garantir qu'on les détecte, et qu'il faut détecter les collisions, on ne le compte pas puisqu'il faudra bien éviter/détecter les collisions d'une façon ou d'une autre.
Collisions qui ne sont plus jamais rencontrées sur les réseaux ethernet modernes, vu que toutes les liaisons sont en full-duplex, et qu'on a au minimum des switches.

Par contre, même si les équipements ethernet longue distance transportent bel et bien les en-tête Ethernet qui sont inutile dans 99% des cas (vu que c'est du point à point et routé au niveau L3 juste après), ils ne transportent bien évidemment pas les "inter-packet" et autres joyeusetés totalement inutiles.

Leon.

corrector

  • Invité
Wifi vs. Ethernet
« Réponse #41 le: 14 août 2016 à 04:15:17 »
Oui, pour le WiFi, je suis d'accord avec toi, c'était une erreur de ma part.
Mais pour l'Ethernet utilisé dans les liaisons longues distances, ça semble bel et bien être des trames Ethernet.
Mais ce qui rentre et sort d'un périphérique wlan sur linux/Windows, c'est bel et bien de l'Ethernet; le comportement d'un wlan qui est configuré en point d'accès Wifi est celui d'un périphérique Ethernet, c'est pour ça qu'on peut le mettre dans un pont Ethernet.

C'est ce qui permet d'avoir un réseau intérieur "plat" : j'accède localement aux PC connectés en filaire comme à ceux connectés en Wifi. Le plan d'adressage n'a pas besoin de faire la différence.

Donc la compatibilité n'est pas assurée par le fait de recopier le structure d'un message avec "L'overhead de 18 octets" "minimum", elle est assurée parce qu'on transmet, d'une façon ou d'une autre, ces trois informations :
Donc pourquoi transporter le formalisme d'Ethernet, avec :
- adresse Ethernet source (6 octets)
- adresse Ethernet destination (6 octets)
- numéro Ethernet de protocole encapsulé (ARP, IPv4, IPv6...) (2 octets)
soit en tout 14 octets.
« Modifié: 20 août 2016 à 20:17:57 par corrector »

thenico

  • Expert.
  • Abonné OVH
  • *
  • Messages: 1 002
  • FTTH >500 Mb/s (13)
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #42 le: 14 août 2016 à 04:42:21 »
Mais ce qui rentre et sort d'un périphérique wlan sur linux/Windows, c'est bel et bien de l'Ethernet; le comportement d'un wlan qui est configuré en point d'accès Wifi est celui d'un périphérique Ethernet, c'est pour ça qu'on peut le mettre dans un pont Ethernet.
Le WiFi comme réseau Ethernet est un cas d'une abstraction qui explose quand on la regarde d'un peu trop prés (WDS pour la 4ième MAC qui manque ...).

corrector

  • Invité
Wifi vs. Ethernet
« Réponse #43 le: 14 août 2016 à 04:47:53 »
Mais du coté AP ça marche bien. Après il faut passer 4addr. 
« Modifié: 20 août 2016 à 20:17:46 par corrector »

corrector

  • Invité
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #44 le: 20 août 2016 à 20:17:30 »
Juste une supposition sans fondement précis : peut-être que la perte de 4% est négligeable dans tous les cas présentés, par rapport aux alternatives ?
Et en particulier, la sortie de ces liens est directement utilisable par des équipements réseaux "standards" et "courants".
Il arrive aussi qu'une technologie soit si courante qu'elle en devient très peu chère en frais connexes: maintenance, profils de salaires, équipements et disponibilités d'équipements de remplacement. Et du coup qu'elle supplante largement les alternatives "un peu plus efficaces" mais trop chères en comparaison.
N'importe quoi, de quelle techno tu parles?

Il y a plus de technos Ethernet que de supports possibles, et il y a beaucoup de supports pour Ethernet :

support partagés (collisions) :

- coaxial "gros" 10BASE5
- coaxial "fin" 10BASE2
- 1 paire torsadé

support dédié :

- 2 paires torsadées
- 4 paires torsadées (Gigabit Ethernet)
- 2 fibres optiques, 1 longueur d'onde (différents types de fibres)
- 1 fibre optique, 2 longueurs d'ondes

support partagé (temps partagé) :

- EPON : 1 fibre optique, 2 longueurs d'ondes
« Modifié: 20 août 2016 à 20:45:44 par corrector »

  • Invité
Overhead Ethernet : 14 ou 18 octets?
« Réponse #45 le: 20 août 2016 à 20:27:00 »
Ah, je n'ai pas compris pourquoi. Peux-tu stp expliquer un peu plus? L'overhead de 18 octets n'est-il pas le minimum repris sur chaque implèmentation "physique" d'Ethernet? (en plus d'être utilisés dans la représentation logicielle d'une trame Ethernet).
Y a-t-il des implèmentations "d'Ethernet over xxx" qui suppriment/compressent une partie de l'overhead inutile?
Autre chose que je n'aurais pas assimilé?
Déjà est-ce qu'une implèmentation d'Ethernet doit considérer le checksum comme une donnée arbitraire? Autrement dit, doit-elle prendre en charge des trames dont le checksum est faux?

Si non, alors les mécanismes existants de détection d'erreur d'une couche inférieure peuvent remplacer le checksum Ethernet. C'est ça qui m'a fait tiquer sur ton "l'overhead est de 18 octets".

Je pense que le checksum est un moyen de détection des corruptions et qu'il ne fait pas parti de l'abstraction présentée. Donc surcharge protocolaire = addr source, dest, proto; c'est tout!

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #46 le: 20 août 2016 à 20:29:34 »
Intel livre ses modules photoniques : « Intel intégrera progressivement les communications optiques dans ses puces »,. Cela signifie que les communications utiliseront la lumière pour circuler à l'intérieur des ordinateurs.
[...]
La technologie sera basée sur le protocole Ethernet très courant, mais les serveurs auront besoin de commutateurs spéciaux pour supporter la vitesse des composants photoniques sur silicium.
source : Le Monde Informatique

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 602
  • La Madeleine (59)
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #47 le: 20 août 2016 à 20:33:58 »
Citer
Les premiers modules photoniques sur silicium d'Intel assurant les transferts entre serveurs sont disponibles.
Révolution, c'est une cage SFP + un patch de fibre ?

Je n'ai pas compris