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/
