Attention à l'algo TCP utilisé, il en existe plusieurs et certains fonctionnent bien mieux avec fort débit + fort RTT. (chaque extrémité gère son algo localement pour les paquets émis et à réémettre)
Quelques notes assez anciennes mais toujours utiles : Linux :: Algos de contrôle de congestion TCP Source : http://linuxgazette.net/135/pfeiffer.html # Algos dispo Voir la liste des algos dispo sur ce linux : ls /lib/modules/`uname -r`/kernel/net/ipv4/ ls /lib/modules/3.2.0-69-generic/kernel/net/ipv4/ tcp_bic.ko tcp_diag.ko tcp_highspeed.ko tcp_htcp.ko tcp_hybla.ko tcp_illinois.ko tcp_lp.ko tcp_probe.ko tcp_scalable.ko tcp_vegas.ko tcp_veno.ko tcp_westwood.ko tcp_yeah.ko De base sur un ubuntu 12.04 : cubic Exemple de cas de pertes pertes de paquets sur un réseau d'une mauvaise DSP, iperf en cubic : 8mbps. Le passage en scalable a permis de monter à 15mbps # Changer l’algo par défaut echo "scalable" > /proc/sys/net/ipv4/tcp_congestion_control # iperf iperf peut aussi changer l’algo à la volée iperf -Z scalable Le ven. 13 déc. 2019 à 10:26, Frederic Dumas <f.du...@ellis.siteparc.fr> a écrit : > > > 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/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
