Tu veux dire : une box qui permet des Speedtest de 8Gbps, par rapport à à une LB5 qui permet 2 Speedtests à 1Gbps ?

Justement, depuis la sortie de la livebox5 une box qui est censée faire du 10 Gb/s doit pouvoir faire du 2*1 Gb/s. Rares sont ceux qui sont équipés pour profiter directement du 10 Gb/s.

Justement, depuis la sortie de la livebox5 une box qui est censée faire du 10 Gb/s doit pouvoir faire du 2*1 Gb/s. Rares sont ceux qui sont équipés pour profiter directement du 10 Gb/s.

Encore plus rares sont ceux qui ont eu besoin de 2*1Gbps.
La preuve : personne ne s'en est plaint en 10 mois 😀

En Ethernet, normalement il y a le flow control : quand les buffers d'un switch ou d'une carte réseau sont presque pleins, ils vont envoyer une trame pause qui demande d'arrêter temporairement les envois. Le buffer du switch doit être dimensionné pour qu'il n'y ait pas de perte de trames le temps d'envoyer la demande de pose, et qu'elle soit traitée (et que les données restent donc dans les buffers côté SoC).

Il y a peut-être un bug quelque part qui fait que le flow control ne fonctionne pas.
Il pourrait être intéressant de faire des iperf UDP entre un PC à 100Mbps sur le switch et :
 - un PC à 1Gbps sur le switch : le flow control devrait fonctionner
 - un PC à 10Gbps : pour que le flow control fonctionne, il faut qu'il soit bien géré sur le switch, remonté au SoC, puis émis par le SoC vers le PC
Avec flow control, iperf devrait donner 100Mbps, sans il donnera 1Gbps/10Gbps avec 90%/99% de pertes.

L'absence de gestion du flow control peut aussi causer des problèmes, même avec tous les PC au même débit.
Si une machine est fortement chargée, ou sur un laptop si la carte réseau a besoin de temps pour sortir d'un mode d'économie d'énergie (par exemple avec l'ASPM du PCIe : tant que le lien n'est par réveillé la carte ne peut pas faire de DMA, et n'a donc que ses buffers, qui sont en général tout petits), on peut avoir des pertes de trames, qui font indirectement chuter le débit TCP (surtout quand la durée avant réémission laisse le temps à la carte de repasser en économie d'énergie...).

A noter que le controlleur Marvell fait du cut-through (https://en.wikipedia.org/wiki/Cut-through_switching) et non pas du store-and-forward: il n'a donc pas besoin de gros buffers.

Peu probable quand l'uplink est à 2.5 Gbps : je ne vois pas comment il pourrait faire passer à 1 Gbps un flux arrivant à 2.5 Gbps sans faire du store.

Ce n'est pas le buffer du switch le problème mais plutot le SoC: en download, c'est son interface à destination du switch qui sature.

Là notre cas, c'est :

Serveur ==10Gb/s==> Internet ==10Gb/s==> SoC ==2,5 Gb/s==> Switch 88E6141 ==1Gb/s==> PC

J'ai préconisé 1 Mo, c'est un idéal pour un débit de 2,5 Gb/s, mais avec un buffer de 1 Mb (125 Ko), on devrait quand même pouvoir assurer un comportement pas catastrophique sans flow control.

Maintenant il est possible qu'il soit possible de configurer le buffer de manière logiciel et qu'il ne soit pas utilisé à son maximum par défaut ou alors qu'il soit séparé entre plusieurs files de QoS pour la priorisation : si il sait gérer des flux avec différents niveaux de priorisés, il est probable que chacun ait ses propres buffers tout comme une séparation download et upload.

Concrètement un ONT Gpon que j'ai étudié à 1 Mo du buffer, a se répartir entre toutes les filles et down / up. Quand tu as 16 files de priorisation, si tu répartie équitable le Mo, c'est 1 Mo qu'il faut diviser par 32 (16 files up et 16 files down) : là on a un buffer trop petit (32 Ko par file).

Maintenant, inutile de mettre de gros buffers sur des files strictement priorisées, on sait que le trafic sur ces files strictement priorisés étant de quelques dizaines de Kb/s pour la VoIP ou quelques Mb/s pour le TvoIP : aucun risque d'être buffurisés : ces buffers peuvent être récupérés pour le trafic internet.