Bonjour C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il peut aussi y avoir des soucis liés à la latence sur le lien qui peut diminuer fortement le débit atteignable en tcp. J'ai déjà eu aussi des effets particulièrement forts de l'interaction entre politique de firewalling et offloading des cartes réseaux. Le débit passait de 70Mo/s à 250 Mo/s en désactivant l'offloading ( ethtool -K ens192 tso off) sur certaines version de redhat.
Tout ça pour dire que ce genre de constat dépend parfois de paramètres très complexes à identifier Thierry CHICH -----Message d'origine----- De : frnog-requ...@frnog.org <frnog-requ...@frnog.org> De la part de Olivier Tirat BYON Envoyé : vendredi 18 décembre 2020 12:25 À : Nicolas Parpandet <n...@1g6.biz>; frnog-tech <frnog-t...@frnog.org> Objet : Re: [FRnOG] [TECH] lien de transit SFR Bonjour Bon différence majeur entre udp et tcp... l'aquittement des paquets.... (TCP ACK). On peut tester un upload indépendament du download ent UDP mais pas du tout en TCP. Il faut faire gaffe au debit en download, s'assurer qu'il y a la place dans le tuyau pour les paquets TCP ACK. Et bien geré la fenêtre pour eviter les TCP RETRANSMIT.... Si en fait ton lien passe les 850 Mbit/s en udp c'est que le niveau peut atteindre ces performances indépendamment. Donc le problème en TCP ne doit pas venir du lien. Après tester des performances réelles d'un transit c'est pas facile car ca dépend aussi de l'autre extrémité....;) Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit : > > Bonjour, > > Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte > bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si > il y avait une QOS quelque part sur les sessions TCP, (le chiffre de > 100Mbits/s revient tellement souvent dans nos tests, la probabilité > que cela soit lié au hasard me semble faible...) > > De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à > 350Mbits... > > Cela fait plusieurs semaines que nous échangeons dans tous les sens > avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le problème, > et cela n'avance pas ! > > est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de > limite avec cet opérateur ?, nous avons fait énormément de contrôles > de notre côté, il me semble que c'est bien en face le soucis ..., il peut > toujours subsister un doute, mais si quelqu'un à une expérience sur le sujet ! > > Merci, A+ > > Nicolas > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
