La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: brupala le 11 novembre 2025 à 15:19:32
-
[Edit modération : hors sujet déplacé, en provenance de https://lafibre.info/gpon/50g-pon/msg1138348/#msg1138348]
C'est quasi certain qu'il y a des mécanismes de QoS, de style Round-Robin ou équivalent, au niveau du GPON et des techno PON.
La preuve? Sur un même arbre GPON, si un utilisateur sature sa connexion (avec des flux UDP plus grand que le tuyau par exemple), alors il voit son ping augmenter fortement, avec des pertes de paquet, et pourtant les ping des autres utilisateur restent normaux.
C'est certain que ça existe en uplink, et il faudrait tester ça pour la partie downlink; il est probable que ça existe aussi en downlink, pour gérer le cas d'un utilisateur qui se prend un (D)DoS, pour ne pas que ça impacte ses voisins.
Je vous invite à faire le test.
Et même à l'intérieur d'un unique accès, d'un unique client, il y a priorisation entre le flux téléphonique et le reste. Souvent avec un VLAN séparé prioritaire pour la téléphonie.
Ces mécanismes sont en effet indispensables.
Les protocoles mobiles sont bourrés de mécanismes QoS comme ça, pour répartir équitablement les ressources, limiter, prioriser. J'imagine que ces mécanismes existent aussi pour les techno PON.
Si des clients constatent ici qu'il y a des pertes de paquet chez leur FAI (Free comme nous le dit kgersen) alors il serait temps de changer de FAI. Un FAI FTTH normal n'a pas de perte de paquets. Moins de 0.1% de perte sur un FTTH normal.
Leon.
A ce propos,
je me demande comment on peut faire des speedtest à 2 Gbit/s sur un GPON ou à 8 Gbit/s sur XG-PON, pareil pour la flux montant, mesuré proche du débit total du lien multiplexé.
Ou alors, ce sont des valeurs pic en fait mesurées sur 1 ou 2 millisecondes, ce qui est suffisant à ces débits (c'est déjà pas mal d'octets et de paquets IP), 1 seconde à 8 Gbit/s, c'est 1 GO soit 1 million de paquets de 1K octets, 1 ms suffirait donc pour mesurer 1000 paquets, 200 paquets sur 1 GPON , je me demande pourquoi les speedtest ont l'air de durer 10s alors qu'une ms de saturation du support suffit, mais bon il y a le temps de connexion de deux ou 3 sessions TCP.
Ce qui fait que quelques ms de saturation de la liaison sur un test de débit devient relativement indolore, tant qu'il n'y en a pas 500 en même temps.
-
C'est le temps que la fenêtre TCP s'adapte, pour avoir une moyenne significative. Le débit ne peut pas être au maximum dès le début.
-
A ce propos,
je me demande comment on peut faire des speedtest à 2 Gbit/s sur un GPON ou à 8 Gbit/s sur XG-PON, pareil pour la flux montant, mesuré proche du débit total du lien multiplexé.
Ou alors, ce sont des valeurs pic en fait mesurées sur 1 ou 2 millisecondes, ce qui est suffisant à ces débits (c'est déjà pas mal d'octets et de paquets IP), 1 seconde à 8 Gbit/s, c'est 1 GO soit 1 million de paquets de 1K octets, 1 ms suffirait donc pour mesurer 1000 paquets, 200 paquets sur 1 GPON , je me demande pourquoi les speedtest ont l'air de durer 10s alors qu'une ms de saturation du support suffit, mais bon il y a le temps de connexion de deux ou 3 sessions TCP.
Ce qui fait que quelques ms de saturation de la liaison sur un test de débit devient relativement indolore, tant qu'il n'y en a pas 500 en même temps.
La question n'est pas super claire, donc je réponds peut-être à côté de la plaque, tu me diras.
En fait, il y a saturer et saturer... Le mot saturation a plusieurs signification du côté des "spécialistes". Je pense que c'est ça qui te pose des problèmes de compréhension.
Un speed test n'a pas pour vocation à pousser plus de donnée qu'il ne peut en rentrer dans le tuyau, l'objectif n'est pas de faire un DoS sur ta connexion et de la détruire.
Le speedtest va utiliser les protocoles standard de contrôle de flux : TCP-RWIN/SWIN, BBR, Cubic, etc... Tout ça pour ajuster en temps réel le débit à ce que permet réellement la liaison IP, de bout en bout, entre le serveur et toi, sans pour autant détruire la liaison.
Ces algorithme sont très efficaces, surtout sur une liaison stable de bout en bout, et ils poussent juste ce qu'est capable de tenir ta liaison IP.
Ils détectent la limite avec la détection de paquets perdus dès que ça sature réellement, et ils perdent très peu de paquets au final.
Donc en gros, tu atteins 99% du maxi de ta connexion, automatiquement.
A l'opposé, n'importe qui peut coder ou utiliser un test dégueulasse qui consiste à envoyer en UDP plus qu'il ne peut rentrer dans le tuyau, et constater que ça détruit la liaison (et en downstream, ça fait parfois tilter des protections dans les équipements du FAI). C'est le principe du DoS.
Leon.
-
La question n'est pas super claire, donc je réponds peut-être à côté de la plaque, tu me diras.
En fait, il y a saturer et saturer...
Le speedtest va utiliser les protocoles standard de contrôle de flux : TCP-RWIN/SWIN, BBR, Cubic, etc... Tout ça pour ajuster en temps réel le débit à ce que permet réellement la liaison IP, de bout en bout, entre le serveur et toi, sans pour autant détruire la liaison.
Ces algorithme sont très efficaces, surtout sur une liaison stable de bout en bout, et ils poussent juste ce qu'est capable de tenir ta liaison IP.
Ils détectent la limite avec la détection de paquets perdus dès que ça sature réellement, et ils perdent très peu de paquets au final.
Donc en gros, tu atteins 99% du maxi de ta connexion, automatiquement.
A l'opposé, n'importe qui peut coder ou utiliser un test dégueulasse qui consiste à envoyer en UDP plus qu'il ne peut rentrer dans le tuyau, et constater que ça détruit la liaison (et en downstream, ça fait parfois tilter des protections dans les équipements du FAI). C'est le principe du DoS.
Leon.
Oui, en fait on ne se comprend pas bien:
Mon propos était de dire que les résultats d'un speedtest montrent que l'on peut utiliser à ce moment là toute la capacité du multiplex (l'arbre PON), si on met localement toutes les chances de son côté, mais que ça ne doit durer que quelques ms car ça n'impacte pas beaucoup les autres utilisateurs.
Le reste, qui plus ton propos:
Forcément, si ça durait plusieurs minutes ça ferait certainement un gros DOS de pas mal de gens, et pas que sur l'arbre sans doute, surtout sur un XG-PON où les uplink de l'OLT ne sont sans doute pas beaucoup plus puissants, mais sur quelques centaines de paquets IP, ça ne se voit pas.
Après, c'est sensé mesurer la partie la plus faible de la liaison seulement, pas la plus puissante, c'est influencé sur la charge globale bien sûr, à ce moment là les mécanismes de fenêtres et algo TCP vont entrer en ligne de compte, donc je pense que le résultat c'est juste un comptage de ce qui est reçu de chaque bout au total, l'idée étant d'avoir plusieurs connexions en parallèle pour continuer sur d'autres si une fenêtre TCP se retrouve bloquée.
Un test iperf qui potentiellement peut durer beaucoup plus longtemps serait bien plus destructeur, surtout si on le fait en UDP, mais heureusement, il y a une limite de débit dans ce cas (1 Mbit/s il me semble).
-
Oui, en fait on ne se comprend pas bien:
Mon propos était de dire que les résultats d'un speedtest montrent que l'on peut utiliser à ce moment là toute la capacité du multiplex (l'arbre PON), si on met localement toutes les chances de son côté, mais que ça ne doit durer que quelques ms car ça n'impacte pas beaucoup les autres utilisateurs.
Je pense que tu n'as toujours pas compris le principe.
Un test de débit reste au débit maxi beaucoup plus que quelques millisecondes! C'est plutôt une dizaine de secondes.
Et si tu constates que tu peux faire quasiment 2.4Gb/s sur un arbre GPON et quasi 8Gb/s sur un arbre XGPON, c'est que ces arbres PON sont tout simplement très très peu remplis. C'est aussi simple que ça.
La plus grande partie du temps, un utilisateur lambda ne génère quasiment aucun trafic sur son FTTH monstrueusement grand, ou juste 1 ou 2 streaming de 10Mb/s, ou un flux 4k à 20-30Mb/s, ce qui est bien maigre par rapport aux 8Gb/s vendus.
(Oui, on peut faire 600 à 800 streaming HD sur un XGSPON sur lequel il y a une cinquantaine d'abonnés maxi).
Du jeu en ligne (hors téléchargement d'update), c'est quelques Mb/s tout au plus.
Un appel visio Whatsapp sur un smartphone, c'est quelques Mb/s.
Je continue, ou alors tu as compris ?
Et non, un speed test ne perturbera évidemment pas les autres utilisateurs.
Leon.
-
Je pense que tu n'as toujours pas compris le principe.
Un test de débit reste au débit maxi beaucoup plus que quelques millisecondes! C'est plutôt une dizaine de secondes.
Et si tu constates que tu peux faire quasiment 2.4Gb/s sur un arbre GPON et quasi 8Gb/s sur un arbre XGPON, c'est que ces arbres PON sont tout simplement très très peu remplis. C'est aussi simple que ça.
La plus grande partie du temps, un utilisateur lambda ne génère quasiment aucun trafic sur son FTTH monstrueusement grand, ou juste 1 ou 2 streaming de 10Mb/s, ou un flux 4k à 20-30Mb/s, ce qui est bien maigre par rapport aux 8Gb/s vendus.
(Oui, on peut faire 600 à 800 streaming HD sur un XGSPON sur lequel il y a une cinquantaine d'abonnés maxi).
Du jeu en ligne (hors téléchargement d'update), c'est quelques Mb/s tout au plus.
Un appel visio Whatsapp sur un smartphone, c'est quelques Mb/s.
Je continue, ou alors tu as compris ?
Et non, un speed test ne perturbera évidemment pas les autres utilisateurs.
Leon.
Bon, je vais continuer aussi, bien que je comprenne parfaitement ton propos, qui encore une fois n'est pas le mien, tu parles de la charge des autres flux et je te parle de la charge du test lui même, c'est pourtant pas compliqué non plus.
Effectivement le test s'affiche pendant plusieurs secondes, mais je réfléchissais qu'il n'est sans doute pas continu, mais qu'il fonctionne peut-etre par bursts de flux pendant quelques ms, puis une pause pendant quelques centaines de ms entre chaque, afin de pousser au max le débit, mais sans bloquer tout le monde.
Maintenant j'arrête là mes réflexions et j'essaierai de faire des captures plus précises à l'occasion, histoire d'éclairer un peu ce petit mystère de saturer une liaison sans la bloquer.
-
J'avais bien compris, mais tu te trompes encore une fois.
Un speed test, c'est un flux continu de données. Tu as le ramp-up normal au début, le temps que l'algo de gestion de flux converge, puis c'est un flux continu au maxi pendant 5 à 10 secondes.
Donc ça ne fonctionne pas du tout comme tu l'imagines, ça ne fonctionne pas avec des burst espacés.
Ce que tu imagines ne permettrait pas de bénéficier de l'algo de gestion de flux, c'est impossible avec de petits burst.
Vivien avait fait plein de captures différentes ici même, avec des courbes de débit instantané pendant les speed-tests.
Leon.
-
J'avais bien compris, mais tu te trompes encore une fois.
Un speed test, c'est un flux continu de données. Tu as le ramp-up normal au début, le temps que l'algo de gestion de flux converge, puis c'est un flux continu au maxi pendant 5 à 10 secondes.
Donc ça ne fonctionne pas du tout comme tu l'imagines, ça ne fonctionne pas avec des burst espacés.
Ce que tu imagines ne permettrait pas de bénéficier de l'algo de gestion de flux, c'est impossible avec de petits burst.
Vivien avait fait plein de captures différentes ici même, avec des courbes de débit instantané pendant les speed-tests.
Leon.
Donc, on bloquerait tout l'arbre le temps du test pour lire un résultat du niveau du débit global ?? ou alors on n'arriverait à des résultats minables si d'autres ont la même idée à ce moment là ?
De plus, je ne pense pas que le but soit d'utiliser l'algo de gestion TCP, si on peut l'éviter.
-
Donc, on bloquerait tout l'arbre le temps du test pour lire un résultat du niveau du débit global ?? ou alors on n'arriverait à des résultats minables si d'autres ont la même idée à ce moment là ?
De plus, je ne pense pas que le but soit d'utiliser l'algo de gestion TCP, si on peut l'éviter.
J'abandonne. Tu pars avec beaucoup trop d'à-priori, de fausses idées que tu n'arrives pas à défaire de ta tête. J'ai tout expliqué dans mes précédents messages, je t'invite à les relire calmement, en essayant au maximum d'oublier tes idées préconçues.
Et si d'autres membres veulent prendre le relais pour expliquer avec des mots différents des miens, pourquoi pas.
Leon.
-
J'abandonne. Tu pars avec beaucoup trop d'à-priori, de fausses idées que tu n'arrives pas à défaire de ta tête. J'ai tout expliqué dans mes précédents messages, je t'invite à les relire calmement, en essayant au maximum d'oublier tes idées préconçues.
Et si d'autres membres veulent prendre le relais pour expliquer avec des mots différents des miens, pourquoi pas.
Leon.
Effectivement,
je serais preneur d'autres explications plus techniques, oui, les tiennes, qui sont plutôt des affirmations, genre ça En fait, il y a saturer et saturer... Le mot saturation a plusieurs signification du côté des "spécialistes". Je pense que c'est ça qui te pose des problèmes de compréhension.
n'arrivent pas à m'éclairer.
-
Tu cherches pas à comprendre tu cherches à affirmer quelque chose sur un sujet que tu ne maitrises pas.
Aucun speedtest peut "bloqué" comme tu dis, un arbre.
Les arbres sont quasi vide et quand bien même y aurait du monde ça changerait rien.
-
Tu cherches pas à comprendre tu cherches à affirmer quelque chose sur un sujet que tu ne maitrises pas.
Aucun speedtest peut "bloqué" comme tu dis, un arbre.
Les arbres sont quasi vide et quand bien même y aurait du monde ça changerait rien.
je parlais le temps du test, je l'ai dit plein de fois, pas du reste du temps, si on le remplit avec le speedtest, il est beaucoup moins vide non ?
Si les arbres sont si vides que ça, sans speedtest, pourquoi y a t-il plein de gens ici à réclamer du XG-pon voire du 50GPON comme on parle ici à la base ?
-
Y a un multiplexage temporel dans les PON. Chacun des membres de l'arbre a un slot temporel ça t'empêche de d'empiéter sur le voisin Tu peux pas garder le micro ou l'écouteur indéfiniment pour bloquer un voisin pendant un speedtest
-
Donc, on bloquerait tout l'arbre le temps du test pour lire un résultat du niveau du débit global ?? ou alors on n'arriverait à des résultats minables si d'autres ont la même idée à ce moment là ?
Si tu es tout seul à faire ton speedtest sur ton arbre PON, si les autres utilisateurs ne font quasiment rien (quelques dizaines de Mb/s demandés), alors oui l'ONT réserve 99% de la resource de cet arbre juste pour toi.
Il est très très peu probable que 2 speed-tests soient réalisés en même temps par 2 des ~50 utilisateurs d'un même arbre.
Un speed test c'est 5 à 10 secondes, et les utilisateurs en font peut être 1 à 10 par jour grand maximum. 1 seul speedtest quotidien par utilisateur utilise quasi toute la bande passante pendant seulement 0.01% du temps (10s / 3600s / 24h).
Et pour finir, si 2 utilisateurs d'un même arbre PON font un speedtest exactement en même temps, à la seconde près, alors ils verront les débits divisés par 2, pour chacun d'entre eux, l'ONT faisant une allocation équitable de la bande passante.
De plus, je ne pense pas que le but soit d'utiliser l'algo de gestion TCP, si on peut l'éviter.
Encore un à priori qu'il faut défaire de ton cerveau. L'algo de congestion / flow-control TCP est tout le temps utilisé pour chercher automatiquement le débit maxi atteignable. Ca n'est pas juste utilisé dans les situations exceptionnelles/dégradées.
Si les arbres sont si vides que ça, sans speedtest, pourquoi y a t-il plein de gens ici à réclamer du XG-pon voire du 50GPON comme on parle ici à la base ?
2 réponses à cette question "pourquoi les gens achètent du 8Gb/s"
- pour une raison qui m'a toujours échappée, beaucoup de gens aiment avoir toujours plus, même s'ils ne savent pas à quoi ça leur servira (à jouer à qui a la plus grosse? A s'auto-satisfaire avec un speed-test); et ils pensent que 8Gb/s c'est mieux que 1Gb/s. Moi je sais que pour mon usage et pour 99% des usages ça n'est pas le cas.
- Du 8Gb/s, ça va accélérer les gros téléchargements de plusieurs dizaines de Go. Gros update de jeu par exemple. Sauf qu'un gros téléchargement de 100Go à disons 4Gb/s (peu de serveurs atteignent 8Gb/s), ça va durer 5 minutes; au lieu de 20-30 minutes avec du 1Gb/s. Donc c'est du confort. Mais 5 minutes c'est très très court dans le temps, ça ne va saturer l'arbre que pendant 5 minutes, et il est une nouvelle fois peu probable qu'un autre utilisateur de l'arbre veuille faire un speedtest exactement en même temps.
Leon.
-
- Du 8Gb/s, ça va accélérer les gros téléchargements de plusieurs dizaines de Go. Gros update de jeu par exemple. Sauf qu'un gros téléchargement de 100Go à disons 4Gb/s (peu de serveurs atteignent 8Gb/s), ça va durer 5 minutes; au lieu de 20-30 minutes avec du 1Gb/s. Donc c'est du confort. Mais 5 minutes c'est très très court dans le temps, ça ne va saturer l'arbre que pendant 5 minutes, et il est une nouvelle fois peu probable qu'un autre utilisateur de l'arbre veuille faire un speedtest exactement en même temps.
Leon.
Outre énormément d'autres usages plus pro à la maison (qui certe sont 0.1% possiblement des usager), ce confort et gain de temps est pour certain non négligeable!
Un exemple, plutôt que d'avoir plein de disque dur etc, je télécharge les jeux à la volés quand je joue, supprime, et le récup la prochaine fois, pourquoi m'embéter à stocker quand cela va me prendre 1/2min à télécharger.
-
Y a un multiplexage temporel dans les PON. Chacun des membres de l'arbre a un slot temporel ça t'empêche de d'empiéter sur le voisin Tu peux pas garder le micro ou l'écouteur indéfiniment pour bloquer un voisin pendant un speedtest
Tout à fait d'accord, mais les slots sont dynamiques et affectés à l'usager qui en a besoin, j'aimerais bien connaitre le principe de l'algo d'affectation d'ailleurs :) Est ce que c'est en fonction des files d'attente dans l'olt et l'ont ?
-
Outre énormément d'autres usages plus pro à la maison (qui certe sont 0.1% possiblement des usager), ce confort et gain de temps est pour certain non négligeable!
Un exemple, plutôt que d'avoir plein de disque dur etc, je télécharge les jeux à la volés quand je joue, supprime, et le récup la prochaine fois, pourquoi m'embéter à stocker quand cela va me prendre 1/2min à télécharger.
C'est à mon avis plus 0,01%, et pour les jeux je doute que tu supprimes le jeu le soir avant de te coucher pour le télécharger à nouveau le lendemain ? Et un jeu à télécharger et à installer il faut plus que 2mn !
-
C'est à mon avis plus 0,01%, et pour les jeux je doute que tu supprimes le jeu le soir avant de te coucher pour le télécharger à nouveau le lendemain ? Et un jeu à télécharger et à installer il faut plus que 2mn !
Cela m'arrive assez souvant en fait ;D surtout quand je veux tester un jeux sur game pass sur une soirée histoire de...
En fonction du jeux et de la plateform, par exemple steam, le téléchargement et l'installation ce fait en même temps, ayant une machine qui suit sans soucis, cela peut tout à fait prendre 2min de bout en bout ;)
-
Cela m'arrive assez souvant en fait ;D surtout quand je veux tester un jeux sur game pass sur une soirée histoire de...
En fonction du jeux et de la plateform, par exemple steam, le téléchargement et l'installation ce fait en même temps, ayant une machine qui suit sans soucis, cela peut tout à fait prendre 2min de bout en bout ;)
C'est vrai que ce truc là a dû augmenter le traffic, le catalogue est tellement grand. Et les jeux aujourd'hui ne font plus 40Go...
Préparez vous à la sortie de GTA VI où tout le monde (estimé à plus de 20M de joueurs) va télécharger 200Go le jour J. Même si ceux qui ont préco auront déjà une pré instal sur leur console, beaucoup vont acheter le jour J.
Là pour le coup je pense qu'Internet va casser.
Pour en revenir au 50G PON, car c'est le sujet de base.
Pas besoin de 50Gb/s, même 4Gb/s suffisent largement pour télécharger/installer un jeux au max des capacité de l'ordinateur et des serveurs en face.
-
C'est vrai que ce truc là a dû augmenter le traffic, le catalogue est tellement grand. Et les jeux aujourd'hui ne font plus 40Go...
Préparez vous à la sortie de GTA VI où tout le monde (estimé à plus de 20M de joueurs) va télécharger 200Go le jour J. Même si ceux qui ont préco auront déjà une pré instal sur leur console, beaucoup vont acheter le jour J.
Là pour le coup je pense qu'Internet va casser.
Pour en revenir au 50G PON, car c'est le sujet de base.
Pas besoin de 50Gb/s, même 4Gb/s suffisent largement pour télécharger/installer un jeux au max des capacité de l'ordinateur et des serveurs en face.
Sur le 50Gb/s et plus, je commence à comprendre le test d'Orange dans un sens.
Pour utiliser beaucoup xcloud/geforce now (malgré ma machine perso) et en pensant au futur, je pense que dans 10/20ans cela pourrait devenir la norme et on achetera plus de console ou pc gaming, just l'interface (headset vr/manette) et tout sera joué via le cloud. Cela fonctionne tellement bien aujourd'hui qu'avec des techo encore mieux et plus rapide, cela va vite devenir indicernable
-
Tout à fait d'accord, mais les slots sont dynamiques et affectés à l'usager qui en a besoin, j'aimerais bien connaitre le principe de l'algo d'affectation d'ailleurs :) Est ce que c'est en fonction des files d'attente dans l'olt et l'ont ?
L'algo en uplink dans un ONT c'est du Round-Robin ou du Weighted-Round-Robin. Et évidemement ça dépend de si chaque utilisateur a (encore) des données à envoyer. Calculé en temps réel, mis à jour en permanence. C'est optimisé, ça ne réserve pas de slots quand ça n'est pas nécessaire et que ça pourrait dégrader la qualité pour les autres.
En downlink, je ne sais pas.
Leon.
-
Je continue mes explications pour brupala
Forcément, si ça durait plusieurs minutes ça ferait certainement un gros DOS de pas mal de gens, et pas que sur l'arbre sans doute, surtout sur un XG-PON où les uplink de l'OLT ne sont sans doute pas beaucoup plus puissants, mais sur quelques centaines de paquets IP, ça ne se voit pas.
Tu as compris ce que faisaient les algorithme de flow-control TCP? Ils ajustent en temps réel le débit à ce que sait supporter ta liaison IP entre ton serveur de speed-test et ton PC. En faisant en sorte de ne pas saturer, de ne pas DOS, de ne pas détruire ta liaison. En gros ils réussissent réellement à utiliser ~98-99% de ce qui est disponible. Et ce en perdant assez peu de paquets.
Et un Speedtest, ça n'est pas foncièrement différent d'un téléchargement. Donc un téléchargement qui dure plusieurs minutes à "vitesse maximale", c'est possible, et ça ne détruira pas ta liaison, grâce à l'algo de flow-control! Si tu télécharges plusieurs dizaines de Go, tu seras dans ce cas là, c'est équivalent à un speedtest de plusieurs minutes.
Et évidemment, la taille du "tuyau" pour 1 seul utilisateur d'un arbre GPON, elle varie en temps réel en fonction de ce que font les autres sur ton arbre GPON, grâce au Round-Robin.
Donc il y a bien 2 algorithmes imbriqués qui marchent de concert
- le round-robin du GPON qui réparti la bande passante entre les utilisateurs, de manière équitable et en temps réel, en fonction des besoins de utilisateurs
- l'algo de flow-control TCP de ton téléchargement / speedtest, qui ajuste en temps réel la quantité de données qui sont "poussées", en fonction de la bande passante disponible (qui est fonction de ce que le round-robin GPON a décidé à la strate du dessous).
Effectivement le test s'affiche pendant plusieurs secondes, mais je réfléchissais qu'il n'est sans doute pas continu, mais qu'il fonctionne peut-etre par bursts de flux pendant quelques ms, puis une pause pendant quelques centaines de ms entre chaque, afin de pousser au max le débit, mais sans bloquer tout le monde.
Si tu as compris ce que j'explique au dessus, alors tu comprendras que ton idée têtue de "bloquer tout le monde" n'a pas de sens. Il n'y a aucune raison qu'un speedtest ou un téléchargement bloque tout le monde.
Leon.
-
La limite de 8 Gbps côté client doit aussi bien aider étant donné que c'est au moins du 10 Gbps derrière, non ? Impossible pour un seul accès de saturer la collecte de l'arbre à lui tout seul. Je ne sais pas si c'est pour cette raison que tous les FAI nationaux donnent 8 et pas 10... mais ça me semble probable :)
Si les 128 clients d'un arbre se mettaient tous à faire un speedtest en même temps, ça devrait laisser environ 120 Mbps par personne. Ça reste mieux que le VDSL ! (bien sûr, dans un environnement parfait ou il n'y a qu'un seul arbre sur cette collecte, et sans tenir compte de la charge utile dans le débit etc.)
-
L'explication usuelle pour la limite a 8 Gbps est l'activation obligatoire du FEC en XGS-PON.
Si on suit la norme: https://www.itu.int/epublications/en/publication/itu-t-g-9807-1-2023-02-10-gigabit-capable-symmetric-passive-optical-network-xgs-pon/en
page 152 (ou section C.10.1.3 en web): le FEC est un code de correction d'erreur de type RS(248,216) donc en gros pour 248 octets transmis, 216 sont utiles , 32 sont des octets de parité. Ca fait donc sur un débit nominal de 9,95328 Gps , un débit utile de 8,66 Gbps ( 9,95328 x 216/248 ). C'est du "line rate" (débit couche 2) pas du débit réseau (IP) ou speedtest (couche 7 ou 4).
Dans la couche PON on fait passer de l'Ethernet dans des paquets GEM et dans Ethernet y'a des entetes, un numero de VLAN, etc donc ca rajoute des bits.
Au niveau couche 2 en comptant VLAN et 1500 MTU on arrive a 8,389 Gbps. Qui serait le max théorique du XGS-PON au niveau 2 (juste avant IP).
┌───────────────────────────────────────────────┐
│ Layer 3: IP (IPv4/IPv6) │
├───────────────────────────────────────────────┤
│ Layer 2: Data Link │
│ ├─ Ethernet MAC (user traffic) │
│ └─ PON TC + GEM encapsulation (PON L2) │
├───────────────────────────────────────────────┤
│ Layer 1: Physical │
│ ├─ Optical signaling (light pulses) │
│ ├─ Line coding, timing, burst mode │
│ ├─ FEC encoding/decoding │
│ └─ Optical fiber + transceivers (medium) │
└───────────────────────────────────────────────┘
Ensuite y'a IPv4 ou IPv6 + TCP c'est au dela qu'on mesure avec speedtest ou iperf3.
(calcul plus précis a faire mais on n'a pas toutes les données réelles).
-
La limite de 8 Gbps côté client doit aussi bien aider étant donné que c'est au moins du 10 Gbps derrière, non ? Impossible pour un seul accès de saturer la collecte de l'arbre à lui tout seul. Je ne sais pas si c'est pour cette raison que tous les FAI nationaux donnent 8 et pas 10... mais ça me semble probable :)
Si les 128 clients d'un arbre se mettaient tous à faire un speedtest en même temps, ça devrait laisser environ 120 Mbps par personne. Ça reste mieux que le VDSL ! (bien sûr, dans un environnement parfait ou il n'y a qu'un seul arbre sur cette collecte, et sans tenir compte de la charge utile dans le débit etc.)
Bon, je vais en remettre une couche:
Si tu pompes le max on va dire 8 Gbit/s d'un arbre XG-Gpon, il me parait clair que le temps que tu fais ça, si vous êtes 128, les 127 autres ont zéro à l'instant I. Si ça dure 1ms, ça fait 1MO de données et c'est transparent, si ça dure 10s, ça fait 10 GO mais ça va faire tousser, les multiplexages vont normalement intervenir pour diminuer ta gourmandise et répartir plus équitablement la bande en fonction des besoins des autres.
Après, la régulation TCP, si on est seul ou que les autres morceaux de la liaison ont beaucoup plus ne se mettra pas en route et essaiera de pousser au maximum de la liaison, ça ne ralentira que si le flux est contrarié par d'autres éléments, concurrence, ralentissements pour bufferisation en files d'attente et au pire perte de paquets et retransmissions, là le débit tcp va très vite s'écrouler si ça dure plusieurs secondes/minutes, c'est à ce moment là que les algos TCP vont intervenir pour optimiser, mais sur le (les flux) du speedtest seulement, pas sur les autres utilisateurs, pour les autres c'est aux matériels actifs du réseau d'agir, au pire en mettant à la corbeille une partie des flux les plus gênants, si ils ne sont pas marqués prioritaires, QOS ordinaire quoi.
Si je calcule bien, à 8 Gbit/s, un paquet de 1000 octets dure à peu près 1 micro seconde, donc retarder une dizaine de paquets, pour en passer d'autres, ça ne change pas grand chose.
un test nperf que j'ai mesuré approximativement sur un lien 1 Gbit/s envoie environ 700 000 paquets, un toutes les 35µs en gros, ça laisse donc peu de temps le support libre, contrairement à ce que je pensais.
-
Je me suis permis de déplacer ce hors sujet dans une section plus appropriée. Vous pouvez continuer la discussion sans problème.
Leon.