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
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
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
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
On 12/12/2019 10:19, Frederic Dumas wrote:
C'est une question de curiosité, pas un problème réel dans le cas
présent.
En général le rtt (et donc la vitesse de la lumière), et le loss sont
une bonne indication du débit théorique que tu peux atteindre en TCP ,;)
--
Raphael Mazelier
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é ?
D'après le looking glass de HE,
