Calculer le débit utile (applicatif) à partir du débit brut (physique) avec IPv4 et IPv6
Pour la fibre (pour l'ADSL c'est sur le post Calculer le débit IP en fonction du débit ATM)



Résumé :

Fichier LibreOffice Calc avec les calculs : calcul_debit_utile.ods (fichier également lisible avec Microsoft Excel)

Bon à savoir : Une interface 1 Gb/s Ethernet gère 1 000 000 0000 bits par seconde (puissances de 1000)
Cale donne 125 000 000 octets par seconde, soit 119,20928955 Mio/s (Les Mio sont des puissances de 1024)
Ces chiffres sont pour le débit brut au niveau de la couche Ethernet.

---

Données utiles par trame Ethernet

MTU de 1500 octets (MTU = taille du paquet au niveau 3 IP du modèle OSI, avec les en-têtes IP)

IPv4 :
- Linux : 1448 octets (option timestamps^* activée)
- Windows : 1460 octets (option timestamps^* désactivée)

IPv6 :
- Linux : 1428 octets (option timestamps^* activée)
- Windows : 1440 octets (option timestamps^* désactivée)

^* Timestamps - est une option qui permet d'Horodatage TCP et permettre d'avoir un débit supérieur dans des situations dégradées (paquets arrivent dans le désordre, pertes de paquets, très forte latence,...). Les Timestamps sont activés par défaut sous Linux et désactivés par défaut sous Windows. Il faut que le serveur et le client activent tous les deux les Timestamps pour que l'option soit utilisée.

---

En-tête de niveau 4 du modèle OSI : TCP

- Linux : 32 octets : En-tête TCP : 20 octets + option timestamps activé par défaut sous Linux (12 octets)
- Windows : 20 octets : En-tête TCP : 20 octets. Pas d'option timestamps par défaut sous Windows

---

En-tête de niveau 3 du modèle OSI : IP

- IPv4 : 20 octets : C'est l'en-tête sans options
- IPv6 : 40 octets : C'est l'en-tête sans options

---

En-tête de niveau 2 du modèle OSI : Ethernet

- Sans VLAN : 18 octets (Wireshark ne prend en compte que 14 octets)
- Avec VLAN : 22 octets (Wireshark ne prend en compte que 18 octets)

Détails :

• 6 octets pour l'adresse MAC de destination ;
• 6 octets pour l'adresse MAC source ;
• 2 octets pour la longueur en octets du champ de données (champ EtherType) ;
• 4 octets pour le VLAN - 802.1Q (optionnel mais souvent utilisé par les opérateurs) ;
• 4 octets pour le Frame Control Sequence qui contient un CRC [Cyclic Redundancy Check] (invisible sur une capture Wireshark).

---

En-tête de niveau 1 du modèle OSI : Couche physique

En-tête de niveau 1 : 20 octets

Détails :

• 8 octets pour le préambule + début du délimiteur de trame (invisible sur une capture Wireshark)
• 12 octets pour le délai inter-paquet (InterPacket Gap). Ce délai normalisé (spécification IEEE 802.3) est fixé à 12 octets (96 bits - soit 0,096 µs sur un Ethernet 1Gb/s), il détermine le temps pendant lequel une station doit attendre entre l'émission de deux trames successives. Il est invisible sur une capture Wireshark.

---

Données brut par trame Ethernet

- Sans VLAN : 1538 octets soit 81 274,4 trames par secondes sur un lien 1 Gb/s
- Avec VLAN : 1542 octets soit 81 063,6 trames par secondes sur un lien 1 Gb/s

Avec le protocole 4rd (RFC 7600) utilisé par Free pour transporter de l'IPv4 sur un réseau IPv6 only, la taille a la sortie de la box est supérieur de 40 octets par trame Ethernet :

- 4rd sans VLAN : 1578 octets^* soit 79 214,2 trames par secondes sur un lien 1 Gb/s
- 4rd avec VLAN : 1582 octets^* soit 79 013,9 trames par secondes sur un lien 1 Gb/s

^* Sous réserve du support des jumbo frames coté WAN, ce qui correspond au 4rd déployé par l'opérateur Free.

---

Petits calculs de ratio de débit utile / débit brut au niveau physique :

IPv4 :
- Windows : 1460 octets utiles (option timestamps^* désactivée)

• Sans VLAN 1460/1538 : Débit de 949,28 Mb/s soit 113,16 Mo/s
• Avec VLAN 1460/1542 : Débit de 946,82 Mb/s soit 112,87 Mo/s
• 4rd sans VLAN 1460/1578 : Débit de 925,22 Mb/s soit 110,30 Mo/s
• 4rd avec VLAN 1460/1582 : Débit de 922,88 Mb/s soit 110,02 Mo/s

- Linux : 1448 octets utiles (option timestamps^* activée)

• Sans VLAN 1448/1538 : Débit de 941,48 Mb/s soit 112,23 Mo/s
• Avec VLAN 1448/1542 : Débit de 939,04 Mb/s soit 111,94 Mo/s
• 4rd sans VLAN 1448/1578 : Débit de 917,62 Mb/s soit 109,39 Mo/s
• 4rd avec VLAN 1448/1582 : Débit de 915,30 Mb/s soit 109,11 Mo/s

IPv6 :
- Windows : 1440 octets utiles (option timestamps^* désactivée)

• Sans VLAN 1440/1538 : Débit de 936,28 Mb/s soit 111,61 Mo/s
• Avec VLAN 1440/1542 : Débit de 933,85 Mb/s soit 111,32 Mo/s

- Linux : 1428 octets utiles (option timestamps^* activée)

• Sans VLAN 1428/1538 : Débit de 928,48 Mb/s soit 110,68 Mo/s
• Avec VLAN 1428/1542 : Débit de 926,07 Mb/s soit 110,40 Mo/s

^* Timestamps - est une option qui permet d'Horodatage TCP et permettre d'avoir un débit supérieur dans des situations dégradées (paquets arrivent dans le désordre, pertes de paquets, très forte latence,...). Les Timestamps sont activés par défaut sous Linux et désactivés par défaut sous Windows. Il faut que le serveur et le client activent tous les deux les Timestamps pour que l'option soit utilisée.

Ce débit utile est un débit théorique en régime établi : TCP n'arrive pas à utiliser 100% de la connexion sachant qu'il ne connaît pas la place disponible, mais il s'en approche fortement, au prix de quelques re-transmissions

Certains opérateurs provisionnent plus (quand la limitation n'est qu'une affaire de fichier de configuration) afin d'éviter cette frustration.

Il est toujours plus plaisant d'avoir 100 Mb/s sur SpeedTest pour une offre 100 Mb/s.

Sur RESO-LIAin, le switch ont des ports 100 Mb/s il me semble donc il est difficile de provisionner 108 Mb/s (nécessaire pour avoir 100 Mb/s utile en IPv6)

Bonjour!

J'ai refait les calculs différemment pour ma situation: Abonné Numéricâble 100 Mégas en zone verte. Modem principal Netgear CG3100L (100/5 Mégs), et modem d'appoint HD-Box Memory Sagem (30/1 Mégs). PC Seven 64, réseau Gigabit. Numéricâble n'utilise pas de tags VLAN. J'utilise IPv4, sans l'option TCP timestamps apparemment, en tout cas je n'en vois pas dans Wireshark. Donc par rapport à ton calcul, j'économise 16 octets en en-têtes, chaque paquet peut transporter 1460 octets utiles, en consommant 1538 octets sur la "ligne".

---

Donc coté Netgear CG3100L, pour exactement 100 Mbits/s bruts provisionnés, le débit utile maximal devrait pour moi être de:

• (1460 / 1538) × 100 = 94,93 Mbits/s utiles

C'est bien ça? Vérifions-le en pratique:


Pfiou!

---

Maintenant coté HD-Box Memory Sagem. Ce qui est provisionné n'est pas 30, mais exactement 30,72 Mbits/s bruts. Donc le débit utile maximal devrait être:

• (1460 / 1538) × 30,72 = 29,16 Mbits/s utiles

Résultat pratique:


Rhaah zut: Ça ne colle pas à deux centièmes de Méga près... je suis déçu, mais alors déçu!

---

D'après vous, tout ça veut dire quoi? Mon calcul est valide, et SpeedTest Massy est extraordinairement juste, encore bien plus juste que ce qu'on imaginait? Ou la coïncidence est accidentelle, et mon calcul erroné?

Donc quand on a un forfait 300 Mb/s par exemple, la box reçoit 300 Mb/s ni plus ni moins, mais on ne peut pas en profiter complètement dans la mesure où les communications des couches basses Ethernet empiètent sur le débit utile.

Bref, c'est la me chose si tu loue un container sur un bateau avec une tonne à l’intérieur : Tu transportera 1 tonne de nourriture + emballage donc tu aura moins d'une tonne de nourriture.

Ce n'est pas un bon exemple les conteneurs surtout si tu utilises un conteneur complet Tu ne paies pas au volume/poids, tu paies plus au conteneur (qui ont des limites de poids/volume).
1T de nourriture en vrac dans un conteneur ou 1T de marchandise emballée dans un conteneur, ça fait toujours 1T pour un conteneur, tu paieras donc le même prix.

Oui mais pour avoir 1 Gb/s de débit utile il faudra 125x(12,5/11,19)=139,63 Mo/s = 1117 Mb/s.