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.

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.

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.

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 ?

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 ?