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.

 

Et moi je vais en remettre une couche :
Orange te vend 8Gb/s mais la vraie limitation du XGS-PON c'est 10Gb/s (un peu moins)

Un Déni de service, c'est généralement beaucoup plus que le débit que peut atteindre TCP.

Par exemple envoyer 20 Gb/s vers un client c'est du DOS.

Un Déni de service, c'est généralement beaucoup plus que le débit que peut atteindre TCP.

Par exemple envoyer 20 Gb/s vers un client c'est du DOS.

probablement, oui, je ne pratique pas ça et la victime ne voit qu'une partie du volume qui l'attaque.

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

[les protocoles de flow control]Certes ils sont là mais sans effet si la liaison est stable, l'effet ne se fait sentir qu'en cas de problèmes afin de les compenser le plus tôt possible, une liaison sans erreurs et pas trop chargée par exemple entre 2 ports de switch à même débit, on n'a besoin d'aucun algo, on bourre, c'est tout, les cas extrêmes sont gérés au niveau applis ou pas du tout.

Je confirme que tu n'as pas compris ce qu'étaient les algos de flow control TCP, où ils étaient utiles, comment ils se déclenchaient. Mais alors pas du tout.

Non, un flux TCP ne bourre pas bêtement, sans algo de flow control, contrairement à ce que tu dis, c'est tout le contraire.
Les algo de flow control TCP ne sont pas du tout réservés aux situations "en cas de problème, d'erreur, de liaisons instables". PAS DU TOUT!
Non, la limitation de débit n'est pas gérée au niveau des "applications" (=Layer 7), pas du tout, dans le cas d'un téléchargement ou d'un speedtest. (une limitation au niveau applicatif c'est surtout pour du streaming à débit variable en UDP, mais c'est un autre sujet).
Les algo de flow control TCP sont utiles tout le temps, et les effets se font sentir dès que l'application pourrait pousser/tirer plus de débit qu'il ne peut en passer sur la liaison, ce qui est très très fréquent:
 1) très fréquent, sur un téléchargement classique, et même sur un streaming par burst via TCP, etc...
 2) systématique en cas de test de débit, c'est bien ce que tu cherches à tester justement! C'est bien le débit "lissé" obtenu par l'algo de flow control TCP qui sera le résultat de ton test de débit. (Et très souvent le débit volontairement cumulé / réparti sur plusieurs TCP-sessions, mais c'est un détail ici.)

Bref, je t'invite une nouvelle fois à oublier tes à priori faux, à relire nos messages, à te renseigner sur ces algo de flow control TCP et surtout de leur utilité, et à faire des tests de téléchargement "bridés par la liaison". N'importe qui peut régler une interface Ethernet à 100Mb/s par exemple et faire une capture WireShark sur un téléchargement bridé par cette liaison à 100Mb/s, c'est un très bon exercice; en mettant un ping en parallèle, c'est encore mieux pour comprendre. Le débit réel du téléchargement monte progressivement et rapidement, et s'adapte automatiquement aux 100Mb/s disponibles, tout ça grâce à ton algo de flow control TCP, avec très peu de pertes de paquet, juste ce qu'il faut comme paquets "sacrifiés" pour que l'algo de flow control puisse détecter la capacité maxi de la liaison.

Leon.