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.

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 ?

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  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.

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

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.

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).