Merci Fabien, Philippe, Raphaël pour vos réponses.
Par le calcul, je n'arrive pas à retrouver vos conclusions.
Au moment des tests, j'avais un rtt de 174ms en moyenne et un jitter de
10ms. J'étais cappé à 132Mbps (pas MBps, coquille). Et aucun paquet n'a
été réémis; pas de pertes. Si le facteur qui a limité le débit, c'est
comme vous le suggérez la fenêtre TCP et non pas un shapping du trafic
par l'opérateur, la fenêtre aurait été à ce moment là de ~2,8Mio. Je
lisais que sa taille peut théoriquement aller jusqu'au Gio pour laisser
le débit augmenter malgré la latence.
Est-ce que l'explication par le fenêtre trop petite est vraiment la
bonne pour un trafic tcp wan transatlantique cappé à ~130Mbps ?
Frédéric.
--
Frederic Dumas
f.du...@ellis.siteparc.fr
Bonjour,
iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre
iperf.he.net et ma machine. C'est
suffisamment haut pour ne pas poser de problème. Par curiosité,
est-il possible d'identifier aux
alentours de quel hop le shaping serait appliqué ?
J'ai l'impression que ton problème de TCP shapé n'en est pas un, que
c'est juste l'effet de la latence que tu mesures...
En effet, faire de l'iperf en TCP, c'est bon pour un LAN ou à la
limite un WAN national.
Pour la longue distance, si tu veux mesurer une bande passante max,
c'est forcément avec de l'UDP.
Exacte, aussi si tu veux rester en TCP pour charger un circuit a rtt
long, multiplie le nombre de flows:
-P, --parallel # number of parallel client streams to run
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
