J'étais en train de me la posée, demain je ferais des tests FTP sur le réseau et hors pour voir d'où ca peu venir.

Je viens de faire des tests à l'heure problématique.

$ iperf -c 77.199.255.202 -u -i 5 -t 15 -r -p 5002
------------------------------------------------------------
Server listening on UDP port 5002
Receiving 1470 byte datagrams
UDP buffer size:   104 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 77.199.255.202, UDP port 5002
Sending 1470 byte datagrams
UDP buffer size:   104 KByte (default)
------------------------------------------------------------
[  4] local 213.251.129.37 port 3549 connected with 77.199.255.202 port 5002
[  4]  0.0- 5.0 sec    640 KBytes  1.05 Mbits/sec
[  4]  5.0-10.0 sec    640 KBytes  1.05 Mbits/sec
[  4] 10.0-15.0 sec    640 KBytes  1.05 Mbits/sec
[  4]  0.0-15.0 sec  1.88 MBytes  1.05 Mbits/sec
[  4] Sent 1339 datagrams
[  4] Server Report:
[  4]  0.0-15.0 sec  1.70 MBytes    950 Kbits/sec  0.485 ms  126/ 1339 (9.4%)
[  3] local 213.251.129.37 port 5002 connected with 77.199.255.202 port 36796
[  3]  0.0- 5.0 sec    521 KBytes    854 Kbits/sec  0.355 ms    0/  363 (0%)
[  3]  5.0-10.0 sec    343 KBytes    562 Kbits/sec  0.278 ms    0/  239 (0%)
[  3] 10.0-15.0 sec  0.00 Bytes  0.00 bits/sec  0.278 ms    0/    0 (nan%)
[  3] 15.0-20.0 sec  0.00 Bytes  0.00 bits/sec  0.278 ms    0/    0 (nan%)
[  3]  0.0-21.9 sec    867 KBytes    325 Kbits/sec  1.459 ms    0/  604 (0%)


Ce qu'il faut retenir c'est la ligne en gras qui indique qu'il y a 9.4% de perte de paquet dans le sens Paris => Pau
(aucune perte dans l'autre sens).

Je me demande si 21h n'est pas l'heure où tout le monde est devant sa TV donc grosses demande de flux TV (ok c'est du multicast mais le flux TV n'est pas remonté sur Pau si personne ne regarde la chaîne)

A noter qu'a cause de ces pertes de paquet en masses, J'ai rarement le rapport d'erreur car il y a trop de perte de paquet :

[  4] WARNING: did not receive ack of last datagram after 10 tries.


Pour info sur une liaison FTTH sur Pau il est inacceptable d'avoir plus de 0.01% de perte de paquet (je peut expliquer le calcul mathématique qui est derrière si certains sont perplexe)
Là on est 9,4% donc on est à pres de 1000 fois le taux max.

Faudrait juste savoir quel élèment est le coupable maintenant, un routeur qui ne tient pas la charge ou qui a du mal à se stabiliser dans la gestion des flux lors de fortes demandes ?
Quelques tracert ou pingmeters au moment de ces baisses pourraient en dire plus.
Tu peux faire ça ?

Plusieurs problèmes :

- Le réseau est plus ou moins caché (on ne voit quasiment rien, soit il y a du MPLS soit les routeurs ne répondent pas)
- Il n'y a pas de perte de paquet avec ICMP (j'étais avec UDP là)

Citation de: vivien le 29 novembre 2007 à 21:18:33

Pour info sur une liaison FTTH sur Pau il est inacceptable d'avoir plus de 0.01% de perte de paquet (je peut expliquer le calcul mathématique qui est derrière si certains sont perplexe)

allez vas-y vivien je suis perplexe 

Dans l'esprit d'un réseau bien dimensionné, Vivien a totalement raison et pourtant je suis plutôt d'accord avec toi Willemijns.
Car cet idéal n'est pas toujours atteint : si un ou des matos en bout de fibres (switchs, routeurs, ...) sont mal 'calibrés' en fonction de la charge qu'il leur est imposée, forcement il y aura des pertes quoi qu'on fasse.

Formule qui nous donne le débit max TCP en fonction du RTT, des pertes de paquets et de la MSS :
 


L'unité du RTT est la seconde dans la formule.

Exemple :
RTT de 40ms, typique pour le FTTH de Pau + pertes de paquets de 0,01% = Débit max de 20 Mb/s

RTT = temps que met un paquet de la taille du MSS à être envoyé + le temps pour recevoir un acquittement. C'est donc entre environ le temps d'un ping de 32 octet + un ping de 1460 octets divisé par 2.

Voici le tableau du débit max TCP (en Kb/s) en fonction des pertes de paquets (en %) et du RTT (en ms).
J'ai supposé que le MTU est de 1500 octets (le maximum en ethernet, soit un MSS de 1460).
Si le MTU est inférieur (Médiafibre, citéFibre, ...) le débit baisse encore.

https://lafibre.info/images/tuto/debit-max-tcp.html

On retombe sur le même débat sur la taille de la Rwin (tu voulais 2 Mo de Rwin de mémoire ce qui est effectivement nécessaire pour télécharger à 50 Mb/s sur un serveur asiatique avec une seulle connexion TCP.).

0.01% c'est :
- 300 Mb/s entre abonnés Neuf FTTH Pau
- 40 Mb/s vers un serveurs Parisien
- 20 Mb/s vers tous les serveurs Français même les endroit les + reculés comme Pau ou Nice (je rappel que pour joindre un serveur sur Pau, on passe par Paris)
- 10 Mb/s d'upload vers une ligne ADSL Française
- 6 Mb/s vers un serveur américain
- 512  Kb/s vers un abonné satellite (peu importe la où il est)

Sachant que si vous démarrez 2 téléchargements simultanés vous doublez le trafic.

0.01% me semble donc la limite acceptable pour un abonnement grand public à bas prix.
Ce n'est pas l'idéal mais pour moi c'est la valeur à partir duquel il faut se plaindre.

Vous pouvez faire votre propre idée en fonction du débit que vous trouvez acceptable et du RTT de la destination :
https://lafibre.info/images/tuto/debit-max-tcp.html

Mon but est de faire comprendre que 9% de perte de paquet (cf post ci-dessus) cela peut vous sembler peu,
mais c'est C A T A S T R O P H I Q U E.