Bonjour ,
S'il vous plait , besoin de votre aide :
Quel es le débit associé à une trame ethernet (1 seule ) avec :
Taille minimale des données : 46 octets
Taille maximale des données : 1500 octets.
et combien de trames sont véhiculées avec un débit de 100Mb/s
Je sais que c'est une question naive mais ça m'aiderait bcp votre aide .
Merci
Bonsoir
Il me semble qu'avant de se poser cette question, il faudrait se demander si une trame Ethernet est, de façon inconditionnelle, associée à un débit. Pour moi, non (il n'y a a priori aucune notion de temps, ni donc de vitesse, associée à une trame de taille donnée). Mais la question aurait éventuellement un sens si le contexte était indiqué.
Tes dernières questions tournant autour de ce sujet sont assez désarmantes, car elle incluent des affirmations qui apparaissent peu pertinentes dans le cadre général, mais qui pourraient l'être dans des certains cas particuliers que ne précises pas. Imagine, c'est un peu comme si tu nous demandais l'âge du capitaine.
Merci de ta réponse
Le contexte est le suivant : Le debit que je peux véhiculé sur un port RJ45 est de 100Mb/s qui est bien évidement de l'ethernet .
D'après internet , une trame ethernet à une longueur minimum et maximum ,
Je voulais savoir juste le nombre de trames transportés avec un débit de 100mb/ et s'il y a ne formule appropriée qui l'explique .
Ma question peut sembler débutante ou naive , elle m'aiderait à comprendre les relations entre débit , longueur de la trame , temps ...
Merci
Bjr à toi,Envoyé par Linuxman99
Merci de ta réponse
Le contexte est le suivant : Le debit que je peux véhiculé sur un port RJ45 est de 100Mb/s qui est bien évidement de l'ethernet .
D'après internet , une trame ethernet à une longueur minimum et maximum ,
Je voulais savoir juste le nombre de trames transportés avec un débit de 100mb/ et s'il y a ne formule appropriée qui l'explique .
Ma question peut sembler débutante ou naive , elle m'aiderait à comprendre les relations entre débit , longueur de la trame , temps ...
Merci
Tu le dis toi meme , une longueur de trame dépend de son contenu (en particulier les données). Donc le nombre de trames pour le débit considéré
doit certainement VARIER ave la longueur..des trames!. Plus les trames sont courtes...plus tu en "logeras" pour un meme débit.
C'est du moins comme cela que je me l'imagine.
Bonne journée
Sans parler de Ethernet, la quantité transportée est fonction du temps.
Bonjour
Une trame éthernet comprend une entête et une trame de données utiles.
A mon avis il faudrait que vous regardiez du coté du protocole bas niveau comment est défini le débit.
S'il s'agit du débit incluant l'entête alors sachant que l'entête contient une quantité d'octets ou de bit fixe (il y a peut être des bit inutiles de remplissage pour avoir un nombre d'octet entier) suivi d'une trame de données de taille variable là vous pourrez calculer le débit utile sur les données.
En quelque sorte l'entête fait perdre du débit, enfin il y a aussi la notion de temps de latence il me semble entre trame si une tentative de dialogue échoue, ce temps réduira aussi le débit utile de données.
Le réseau éthernet est partagé donc un émetteur n'aura pas 100% du temps 100% de la bande passante.
cdlt
Est ce que la relation suivante est logique :
100Mb / 1500 = nombre de trames ethernet ? ( on considère que la trame ethernet à une longeur de 1500 octets dans mon cas ) .
On n'inclut pas les entêtes , le temps de latence et les bit de stuffning , les IFG
Merci à vous
Par définition, la vitesse indicative d'une liaison Ethernet correspond au débit maximum instantané, basé sur la durée d'un bit. Il s'agit bien d'une durée, et non pas d'un nombre de bits effectivement transmis, qu'ils soient de données ou d'entête.
Le calcul du débit des trames doit prendre en compte toutes les durées nécessaires à leur transmission, notamment celles correspondant :
- aux bits de données (1500 octets)
- aux bits d'entête et de CRC (26 octets)
- aux délais entre trames (équivalent à 12 octets)
soit une durée minimale par trame correspondant au total à la transmission de 1538 octets.
Pour 100 Mb/s, le débit de trame maximum vaut donc 100M/(1538x8) ≈ 8127,4 trames par seconde.
Ce maximum ne prend pas en compte les ralentissements dus au partage de la liaison (collisions, occupation, ...) ni ceux dus aux mauvaises performances des équipements.
donc si je comprend bien :
Une trame de 1538 octets occupe un laps de temps très court (on raisonne toujours en temps , Merci Pascal et les autres) , je parle bien d'une seule trame : 1538/100Mb = ?
J'ai posé la question car j'avais une confusion entre la longeur de la trame et le débit qu'elle peut véhiculer ,
Un équipement utilsant une trame de 1538 octets peut véhiculer même des Go/s , et cela dépend de son architecture interne ? est ce exacte ?
merci à vous
Si la longueur des en-têtes + délai entre trames est fixe (ici 26+12= 38 octets) alors pour chaque trame, on aura 38 octets de "perte". C'est comme la TVA
Donc si tu mets 46 octets de données dans ta trame, tu auras 46 utile (net) plus 38 de "taxe" et donc 84 au total ("brut"). Comme tes 46 octets utiles ne représentent que 54.8% du total, le débit net ne sera que 54.8 Mbps si tu envoies tes trames sans interruption sur un lien à 100Mbps.
Par contre à 1500 octets "net" par trame, ça fait 1538 en "brut" donc 97.5% du débit est utilisé pour transmettre des données utiles.
Dans ce cas on a 1538 * 8 /100e6 = 123 µs par trame et donc 8127 trames par seconde comme expliqué par PA5CAL. Bien sûr avec des trames plus courtes, on peut en envoyer plus par seconde.
> J'ai posé la question car j'avais une confusion entre la longeur de la trame et le débit qu'elle peut véhiculer ,
> Un équipement utilsant une trame de 1538 octets peut véhiculer même des Go/s , et cela dépend de son architecture interne ? est ce exacte ?
En fait c'est assez subtil. Comme tu le vois, quand on tient compte des en-têtes, plus les trames sont petites, plus les en-têtes occupent une proportion importante du débit disponible, or ce n'est pas des octets "utiles" du point de vue de l'utilisateur. Du point de vue du réseau ethernet, c'est très utile puisqu'il y a l'adresse de destination dedans, sans en-tête ça ne marcherait pas.
Donc utiliser des trames trop petites va réduire le débit. D'autre part si chaque trame est aussi un paquet (TCP, UDP) il y aura probablement un effort à faire par le processeur pour construire ce paquet, donc à débit constant augmenter le nombre de paquets va augmenter la charge cpu. De même, chaque switch doit regarder dans ses tables pour savoir où envoyer chaque paquet en fonction de l'adresse de destination. C'est une des raisons pour les jumbo frames sur l'ethernet gigabit, ce sont des trames plus grosses, donc à débit égal il en faut moins, donc le cpu bosse moins.
Par contre des trames plus petites vont diminuer la latence : si ton switch attend d'avoir reçu une trame complète pour la retransmettre vers le switch suivant, il est entendu que cela ajoute dans chaque switch un délai proportionnel à la longueur de la trame. Si ton switch est plus intelligent et retransmet une trame avant d'avoir fini de la recevoir, alors non. Mais dans tous les cas si le lien est déjà occupé à transmettre une autre trame, il faudra attendre qu'elle soit finie avant d'en envoyer une autre, donc on voit que la distribution statistique des longueurs de trame et aussi la charge (utilisation globale de la bande passante) vont déterminer la latence de ton réseau.
Une question bête : quand on dit qu'on a un débit de 100Mbps , ce dernier est le débit utile ? sans les entêtes ... ?Si la longueur des en-têtes + délai entre trames est fixe (ici 26+12= 38 octets) alors pour chaque trame, on aura 38 octets de "perte". C'est comme la TVA
Donc si tu mets 46 octets de données dans ta trame, tu auras 46 utile (net) plus 38 de "taxe" et donc 84 au total ("brut"). Comme tes 46 octets utiles ne représentent que 54.8% du total, le débit net ne sera que 54.8 Mbps si tu envoies tes trames sans interruption sur un lien à 100Mbps.
Par contre à 1500 octets "net" par trame, ça fait 1538 en "brut" donc 97.5% du débit est utilisé pour transmettre des données utiles.
Non, comme je l'ai indiqué, il s'agit du débit de bits instantané.
100 Mbps signifie que la transmission d'un bit dure 0,01 µs. Cette durée unitaire peut correspondre à un temps de transmission d'un bit de données, à un temps de transmission d'un bit d'entête ou à un temps d'attente sans transmission entre deux trames.
Dans ma précédente réponse (trame de 1500 octets utiles à 100 Mbps), il y avait 1500×8 = 12000 bits utiles par trame transmis sur une durée minimale de 1538×8×0,01 = 123,04 µs, ce qui correspond à un débit utile maximum de 12000/123,04 ≈ 97,53 Mbps.
on est d'accord que : trame ethernet = entêtes ( TCP+MAC+IP...) + (46 ou 1500 octets de données ) + 38 octets d'autres entêtes ?
> on est d'accord que : trame ethernet = entêtes ( TCP+MAC+IP...) + (46 ou 1500 octets de données ) + 38 octets d'autres entêtes ?
Non, l'ethernet n'est pas concerné par ce que tu mets dans la partie "données" de la trame. Tout ce qui est TCP/IP/UDP, y compris les headers TCP/IP/UDP est dans les 1500 octets de données. Le header ethernet contient les adresses MAC et autres trucs spécifiques à ethernet. Tu peux très bien utiliser ethernet pour du trafic non IP, si les headers ethernet sont bons avec les bonnes adresses MAC, ethernet amènera la trame à la destination.
> Une question bête : quand on dit qu'on a un débit de 100Mbps , ce dernier est le débit utile ? sans les entêtes ... ?
C'est un débit commercial, donc avec en-têtes. Mais si tu remplis bien tes trames, le débit réel n'est pas fort différent.
Donc 46 ou bien1500 octets contient les entêtes TCP/IP + les données utiles (message , vidéo...) ?
la couche pcs fait partie aussi du 1500 octet ?
Bonsoir,
Je te conseille d'ouvrir Wireshark au moins une fois pour analyser un peu les différentes trames que tu va capturer.
Ça devrait t'éclairer un peu.
Peux-tu m'éclaircir sur les " et autres trucs spécifiques à ethernet." stp ?
merci encore
ethernetement
https://en.wikipedia.org/wiki/Ethernet_frame#Structure
Il y a
- de la "logistique" qui permet aux électroniques à chaque bout du lien de se synchroniser et de bien s'entendre (pause entre paquets, préambule, start of frame)
- bien sûr les adresses source/destination
- un CRC pour détecter les erreurs
- et un champ "type" qui permet éventuellement de configurer les switch pour donner des priorités à certains types de paquets ethernet (c'est peu courant).
