La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => 
Anciens FAI => Opérateurs grand public alternatifs => 
Erenis => Discussion démarrée par: vivien le 14 janvier 2008 à 22:37:49
-
Depuis (c'est a dire le 30 décembre) que je mesure les pertes de paquets (enfin plutôt les retransmissions de paquets) je dois dire que tu a une bonne ligne en download avec 0,001% de paquets retransmis.
En upload tu as 17% de paquets retransmis.
Tu a un nombre de triple Dupack impressionnants.
Voici 2 petits graphique pour te montrer l'état de ta connexion :
(https://lafibre.info/images/wireshark/TCPtaupin1.png)
c'est régulier !
un zoom :
(https://lafibre.info/images/wireshark/TCPtaupin2.png)
Je suis persuadé que tu peut avoir beaucoup plus en upload.
Il faudrais comprendre l'équipement qui est défectueux.
-
En upload, ne penses tu pas plutot qu'étant donné l'offre d'erenis 60Mbits/s / 6Mbits/s ... que c'est un bridage chez eux ? Peu etre qu'en migrant chez neuf, que cette limitation n'existera plus et qu'ainsi, on connaitra le plein potentiel de ma ligne ?
Par contre, c'est quoi ton triple dupack ?
-
Par contre, c'est quoi ton triple dupack ?
The total number of triple duplicate acknowledgments received (three duplicate acknowledgments acknowledging the same segment), a condition commonly used to trigger the fast-retransmit/fast-recovery phase of TCP.
En gros dès que a un paquet qui arrive et qui n'est pas celui attendu, la pile èmet un acquittement sélectif. Si le paquet suivant n'est toujours pas celui le premier attendu, elle recommence, ect... autant de fois que nécessaire.
Coté récepteur, on va laisser passer le 1er et le 2ème acquittement sélectif mais au 3ème on renvoi le paquet manquant.
Bref il y a un gros pb sur ta connexion. Peut être du a un équipement qui ne supporte pas une Rwin de seulement 80 Ko (comme c'est en upload c'est mon serveur qui te fixe la Rwin elle est adaptative et les pertes commence quand elle est vers 80 Ko)
Je suis étonné que le débit ne chute pas plus.
L'idéal serais de faire un dump de ton coté (avec Wireshark ou tcpdump en ligne de commande) afin que je puisse mieux comprendre ce qu'il se passe de ton coté.
Un autre test consisterais a débrancher temporairement ton serveur pour brancher directement un PC (linux ou windows pas d'importance) sur le modem Vdsl avec iperf pour refaire un test. Cela permettrais de déterminer si cela viens de chez toi ou non.
Vivien.
-
Voici ce que donne le graph coté client (pas pour le même test exactement mais le problème se répéte, toujours le même, trés stable)
(https://lafibre.info/images/wireshark/TCPtaupin3.png)
Les paquets sont bien perdu on voit clairement une chute de débit du a la perte de paquet.
Les tests de débits sont quasiment identique a ceux fait mi-décembre :
Tests UDP upload :
5.7 Mb/s :
[ 3] 5.0-10.0 sec 3.40 MBytes 5.70 Mbits/sec 0.159 ms 0/ 2424 (0%)
[ 3] 10.0-15.0 sec 3.40 MBytes 5.70 Mbits/sec 0.091 ms 0/ 2424 (0%)
[ 3] 15.0-20.0 sec 3.40 MBytes 5.70 Mbits/sec 0.120 ms 0/ 2424 (0%)
[ 3] 20.0-25.0 sec 3.40 MBytes 5.70 Mbits/sec 0.107 ms 0/ 2424 (0%)
10 Mb/s :
[ 3] 0.0-30.0 sec 21.0 MBytes 5.86 Mbits/sec 2.203 ms 10553/25505 (41%)
J'aimerais bien comparer avec un autre abonné Erenis.... (ou neuf Vdsl)
-
Comme vous le voyez les pertes de paquets sont brutalement passées de 17% à un peu plsu de 1% (ce qui reste énorme)
(https://lafibre.info/images/wireshark/Debian31a40.png)
La cause ?
Changement du système d'exploitation ;D
-
Comme vous le voyez les pertes de paquets sont brutalement passées de 17% à un peu plsu de 1% (ce qui reste énorme)
...
La cause ?
Changement du système d'exploitation ;D
Juste pour comparer, le même test avec l'ancien os mais 'optimisé' (sans firewall, ni av, ...) serait interressant ;)
C'est possible ?
(au fait, c'est quoi l'ancien os ?)
-
Je suis passé de debian sarge noyau 2.6.8 a debian etch noyau 2.6.18 ...
Pour le test, pourquoi pas ... mais pas avant 1 semaine, j'ai encore des choses a remettre en place en ce moment et ca demande du temps.
-
Je suis passé de debian sarge noyau 2.6.8 a debian etch noyau 2.6.18 ...
Pour le test, pourquoi pas ... mais pas avant 1 semaine, j'ai encore des choses a remettre en place en ce moment et ca demande du temps.
L'ancien était donc une Sarge noyau 2.6.8 ?
Et le nouveau est très exactement installé de la même façon ? ni plus ni moins (aucun outil/option en plus ou moins par rapport à l'install Sarge noyau 2.6.8, ...) ?
Je vais jeter un coup d'oeil sur les diffs Sarge avec noyau 2.6.8 et Sarge avec noyau 2.6.18 pour voir ce qui pouvait coincer.
-
Pour les outils en plus ou en moins ... je te dirais que je ne pense pas ...
Apres, si tu sais comment le savoir exactement, je veux bien le faire.
-
Je vais jeter un coup d'oeil sur les diffs Sarge avec noyau 2.6.8 et Sarge avec noyau 2.6.18 pour voir ce qui pouvait coincer.
Sarge = Debian 3.1 (sortie le 6 juin 2005) = noyeau 2.6.8 par default
Etch = Debian 4.0 (sortie le 8 avril 2007) = noyeau 2.6.18 par default
-
Sarge = Debian 3.1 (sortie le 6 juin 2005) = noyeau 2.6.8 par default
Etch = Debian 4.0 (sortie le 8 avril 2007) = noyeau 2.6.18 par default
Je sais :)
Mais ce n'est pas forcement une question de noyau qui fait qu'il y a cette différence énorme de pertes entre les deux.
C'est pour cela que je demandais quelles sont les installs utilisées (packages installés ou pas, ou par exemple install par défaut, livecd, ...)
-
J'ai fait 2 net install ... et réinstaller les meme services.
Apres, je ne sais pas en détail ce qu'il pourrait avoir de différent.
-
Pour les problèmes des paquets ré-émis en upload je commence a remettre à cause mon programme.
Autant en download c'est simple de détermienr les paquets ré-émis, comme je fais une capture sur le serveur, je compte les paquets ré-émis par mon servur vers le client.
En upload (sens client => serveur) j'additionne le % de paquets arrivés dans le désordre au % de paquet arrivé en double (dés fois quand il manque certians paquets, l'èmetteur ne comprend plus le seclect acquittement et renvoi tous les paquets à partir de la perte ce qui affecte beaucoup le débit)
=> je viens de calculer sur une petite trace (un grand merci au débits pourris de DartyBox qui rend facile une analyse a la main) et je crois qu'il y a un problème, le chiffre de paquet en double arrivé pouvant être faux....
Un exemple de capture auniveau du servuer pour un trafic Client => Serveur :
Quelques pertes de paquets et des paquets ré-émis en double.
-
ooops, non il compte bien....
la pile TCP/IP a de temps en temps le sélectif acquittement qui permet de ne pas ré-èmettre tous les paquets entre le paquet perdu et le paquet actuel ne fonctionne pas tout le temps correctement, il faut que je comprenne mieux le phénomène...
Dans la copie d'écran ci-dessous il y a 23 paquets reçus en double à tord + 4 perte de paquets perdus (enfin paquets arrivés en désordre pour être précis, mais on est sur à 99.9% qu'ils ont été perdu et re-transmis) pour 139 paquets ce qui me donne pour cet exemple 27 / 139 de retransmission en upload soit 19.4% de paquets retransmis
Vous êtes ok avec mon analyse ?