Auteur Sujet: 2007 : pourquoi des mauvais débits vers 21h chaque jour en download ? (Lu 17796 fois)

feyb64 · « **Réponse #12 le:** 01 décembre 2007 à 22:13:13 »

Citation de: vivien le 01 décembre 2007 à 15:58:24

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.).

...

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.

Pour le rwin, plus d'infos dans le tuto ... (cela ne tardera plus, quelques touches finales)

Pour le but, je suis d'accord sur le principe.

Leon · « **Réponse #13 le:** 02 décembre 2007 à 09:23:42 »

Tout cela me rappelle la situation d'il y a 2 ans sur le PBC, avec la montée en puissance d'IPVSET.

Citer

Voila le graphe sur pratiquement 48heures... la densité de rouge montre la frequence a laquelle le seuil de 10% de perte a été atteint. on voit nettement le moment ou l'equipement ne répond plus du tout.

http://vers la machine précédente, il ya aussi une perte de paquets... minime mais existante

Citer

Salut à tous!

J'observe toujours avec intérêt ce qui se passe chez vous depuis ma banlieue Parisienne.
J'ai analysé le ping depuis un serveur hébergé sur Paris vers une machine fiable de votre réseau (l'ordi d'une connaissance), et ce sur 24h . Les 2 machines n'étaient pas du tout chargées pendant le test.

Le constat est affligeant! C'est un bel exemple de liaison qui sature. Le taux de packets perdus atteint plus de 20%!:o
Rappel: en ingénierie réseau, on considère qu'une liaison est sous dimensionnée quand elle est utilisée à plus de 80%. Ici, c'est plus de 110% qui voudraient bien passer par le lien.
Et on voit bien par un traceroute que cette saturation est due à une limitation de débit sur un routeur de Pau. C'est bien un problème de dimensionnement de la liaison Pau-Paris.
Quand la liaison ne sature pas, le ping est à peu près de 15ms, cohérent avec la distance Pau-Paris (- de 800km). C'est d'ailleurs le Ping Paris-Pau constamment observé sur le réseau Free avec la même méthode.

Ce constat explique grandement l'impossibilité de jouer en réseau (très sensible à la perte de packets), et toutes les applications temps réel (visio, tel). Si vous voulez jouer, je vous conseille entre 4h et 9h du mat!
Cela explique également les surfs lents, car les retransmissions doivent être très nombreuses. Bref, si j'étai vous, je gueulerai (monter une pétition, autre), car là c'est assez inacceptable comme prestation.

Citation de: Soulwax
Comme le dit 00110011 c'est surement du à l'abus de certains mais on ne peut pas forcer tous les utilisateurs à renoncer au p2p.
Citation de: 00110011
pour le canal, comme le dit Soulwax, un tel upload est très allechant... d'ou =>grave de l'abus
Je pense que ce genre de problèmes était largement prévisible: L'upload proposé par les FAI de Pau Broadband Country est largement trop élevé pour une offre pérenne à ce prix. Surtout que le projet ne rencontre pas, aujourd'hui, le succès escompté. Qu'en serait-il s'il y avait 10 fois plus de connectés, comme espéré?
Je ne comprend pas que vous parliez d'abus pour ce genre de comportement: l'upload proposé ne serait pas fait pour être utilisé? L'upload est aujourd'hui l'un des seuls arguments valables pour le FTTH en comparaison de l'ADSL pour les zones urbaines denses.

Sur ce, je vous souhaite bien du courrage.

Leon.[/size]

Citer

Salut

Pour m'éclaircir les idées sur la route prise par les paquets entrants et sortants de ma rgw vers un point de l'internet, j'ai réalisé un petit tracert (trace de route).
Notez que j'ai dû réalisé ce test en 'inverse', c-a-dire depuis l'extérieur vers ma rgw, car pour une raison inconnu ma rgw ne laisse pas correctement passer les requêtes tracert (protocole icmp utilisé aussi par les pings) et certains résultats sont faussés !

Voici la route (uniquement la fin interressante) à partir de la sortie du réseau FT (le serveur utilisé est coté FT sur Pau) vers ma rgw (à Pau aussi) :

Citer
6 18 ms 18 ms 18 ms pos14-3.nraub303.aubervilliers.francetelecom.net [193.252.161.110] ---------> Passons la partie FT
7 * * 21 ms 193.251.126.54 ---------> un matos entre les deux (Ft ou opentransit, peu importe ici)
8 18 ms 18 ms 18 ms po2-0.auvbb1.aubervilliers.opentransit.net [193.251.241.182] ---------> on entre chez opentransit.net
9 19 ms 18 ms 18 ms 21stcentury-1.gw.opentransit.net [193.251.248.114] ---------> on sort de opentransit.net
10 19 ms 19 ms 19 ms po9-0.par-gar-core-1.interoute.net [212.23.42.33] ---------> on entre chez interoute.net
11 19 ms 20 ms 19 ms po6-0.par-gar-access-2.interoute.net [212.23.42.18] ---------> on sort de interoute.net
12 20 ms 21 ms 20 ms 212.23.37.178 ---------> un bout de la liaison Paris-Pau coté Paris ou Pau ?
13 36 ms 35 ms 35 ms ge-0-0-ro-erx-hdf-1.pau.axione.fr [217.119.176.10] ---------> on entre chez Axione (l'autre bout ?)
14 36 ms 36 ms * ge-11-0-v211-ro-erx-hdf-1.pau.axione.fr [217.119.178.130] ---------> à priori equipement axione qui raccorde au pbc proprement dit
15 37 ms 36 ms 36 ms 217.119.xxx.yyy ---------> ma rgw (permettez que je cache ...)

Itinéraire déterminé
Déjà pour infos sur 'interoute', le fournisseur de transit d'axione (et de la ligne pau-paris je pense), voici une carte de leur réseau dans ce pdf sur leur site :
http://www.interoute.net/documents/549_Eurotransit_Sheets_AW.pdf en dernière page. (désolé pas eu le temps de récup juste l'image)

On notera sur ce schéma fort interressant que des pop se trouvent entre autres à Paris, Poitier, Bordeaux et Toulouse.
Une question interressante alors : Ou arrive réellement notre ligne pau-paris ? (points 11 ou 12 du tracert). Si directement à Paris, pourquoi ? Il semblerait plus interressant Bordeaux ou Toulouse (et pourquoi pas les deux pour redondance ?). Mais bon, ce n'est qu'un observation qui n'entre pas dans mon propos.

Maintenant passons aux 'basics' tests de pings vers ces différentes ips axione et interoute, de ma rgw vers eux.

Vers ge-11-0-v211-ro-erx-hdf-1.pau.axione.fr [217.119.178.130] (juste après ma rgw, sa passerelle donc, comme certainement celle d'au moins tous les ipvset'istes raccordés à l'Hotel de France) :

Citer
ping -t 217.119.178.130

Envoi d'une requête 'ping' sur 217.119.178.130 avec 32 octets d

Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=2 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=2 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=2 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=2 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=2 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=2 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125
Réponse de 217.119.178.130 : octets=32 temps=1 ms TTL=125

Statistiques Ping pour 217.119.178.130:
Paquets : envoyés = 73, reçus = 73, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 1ms, Maximum = 2ms, Moyenne = 1ms
Ctrl+C
EXTREMEMENT CORRECT ! (certe pas sur longue durée, mais attendez la suite ...)

Vers ge-0-0-ro-erx-hdf-1.pau.axione.fr [217.119.176.10] (certe pas sur longue durée, donc pas forcement la réalité sur les chiffres annoncés, mais ...)

Citer
C:\Program Files\Support Tools>ping -t 217.119.176.10

Envoi d'une requête 'ping' sur 217.119.176.10 avec 32 octets de données :

Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Délai d'attente de la demande dépassé.
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Délai d'attente de la demande dépassé.
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Délai d'attente de la demande dépassé.
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Délai d'attente de la demande dépassé.
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124

Statistiques Ping pour 217.119.176.10:
Paquets : envoyés = 27, reçus = 23, perdus = 4 (perte 14%),
Durée approximative des boucles en millisecondes :
Minimum = 1ms, Maximum = 2ms, Moyenne = 1ms
Ctrl+C
OUPS ! AIE ! OUTCH ! :/ :? :hum :siff
Le délais est encore excellent (1 à 2ms) MAIS une perte de 14% rien qu'entre deux equipements à PAU !

Comme je doute quand même un peu de la rgw, je relance quelques minutes plus tard :

Citer
ping -t 217.119.176.10

Envoi d'une requête 'ping' sur 217.119.176.10 avec 32 octets de données :

Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Délai d'attente de la demande dépassé.
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Délai d'attente de la demande dépassé.
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=1 ms TTL=124
Réponse de 217.119.176.10 : octets=32 temps=2 ms TTL=124

Statistiques Ping pour 217.119.176.10:
Paquets : envoyés = 14, reçus = 12, perdus = 2 (perte 14%),
Durée approximative des boucles en millisecondes :
Minimum = 1ms, Maximum = 2ms, Moyenne = 1ms
Ctrl+C
PAREIL, et sur un plus court nombre de pings !

Je ne vais pas plus loin pour l'instant, je vais refaire ces tests sur une plus longue période.
MAIS BON, force est de constater que :
- Soit je suis tombé dans un 'mauvais' moment sur notre réseau :hum
- Soit IL Y A UN APPAREIL QUI FAIT DU N'IMPORTE QUOI OU EST DEJA SATURÉ DEJA ICI A PAU MEME
ET NOTEZ que la liaison PAU-'Je ne sais ou en réalité' n'est pas encore en cause :siff

S'il n'y a pas de cause 'météorologique' externe, le fautif est donc :
- Soit "ge-11-0-v211-ro-erx-hdf-1.pau.axione.fr [217.119.178.130]" (derrière ma rgw) ou sa carte vers son voisin "ge-0-0-ro-erx-hdf-1.pau.axione.fr [217.119.176.10]"
- Soit ce dernier "ge-0-0-ro-erx-hdf-1.pau.axione.fr [217.119.176.10]" ou sa carte vers le premier
- Soit un hub ou un switch entre les deux (si pas de cable croisé ou utilisation d'un port mdi-x sur l'un deux)
- Soit un câble entre, ou un défaut que un des connecteurs ...

Blaque : ils ont mis un hub 10mb à 5€ entre les deux =D
(quoi que :hum c'est peu être pas une blague après tout :hum bon on va dire un hub 100mb au moins alors =D )

Je me lance sur une analyse plus poussée (sur plus de temps) dès que possible (faut éviter d'utiliser le pc et la rgw ... pas facile ...)

Un premier résultat sur 20mn avec packetloos (merci à leon_m pour l'info sur cet outil) vers les deux matos précédents :
(notez que packetloos fait une serie de pings toutes les minutes et pas en continu comme les bons vieux pings précédents, donc c'est plus 'lissé' avec packetloos

Vers ge-11-0-v211-ro-erx-hdf-1.pau.axione.fr [217.119.178.130] :

Ping moyen : 1ms
Perte : 0%

Vers ge-0-0-ro-erx-hdf-1.pau.axione.fr [217.119.176.10] :

Ping moyen : 1ms
Perte : 4%

C'est quand même 4% !!! Pas normal sur du local pur je trouve !
En pings continu ça doit faire quand même du 10 à 15% comme précédement !
Imaginez un tranfert à 2Mo/s ! sur les 2Mo/s il y en a en fait 4% à 15% en plus qui on essayé de passer sans succés et donc autant de paquets qu'il faut renvoyer !
Et ça rien qu'en local à l'Hotel de France !
Imaginez le résultat si la ligne Pau-Paris est saturée aussi !

Faut vraiment qu'ils vérifient leurs matos à Pau, Axione !

Deuxième résultat sur 2jeures vers les deux matos précédents (j'ai rajouté le plus fort pic de perte par relevé) :

Vers ge-11-0-v211-ro-erx-hdf-1.pau.axione.fr [217.119.178.130] :

Ping moyen : 1ms
Perte : 0%
Pics de perte :

Vers ge-0-0-ro-erx-hdf-1.pau.axione.fr [217.119.176.10] :

Ping moyen : 1ms
Perte : 2%
Pics de perte : 10%

[/size]

Au fond, les problèmes n'ont pas beaucoup changés. Il faudrait un peu plus d'explication de la part des "autorités" du PBC, parce que là, un problème d'il y a 2 ans qui ressurgit, ça n'est pas très normal.

Leon.

vivien · « **Réponse #14 le:** 02 décembre 2007 à 09:54:33 »

Citation de: leon_m le 21 novembre 2005 à 20:57:39

Salut à tous!

J'observe toujours avec intérêt ce qui se passe chez vous depuis ma banlieue Parisienne.
J'ai analysé le ping depuis un serveur hébergé sur Paris vers une machine fiable de votre réseau (l'ordi d'une connaissance), et ce sur 24h . Les 2 machines n'étaient pas du tout chargées pendant le test.

Le constat est affligeant! C'est un bel exemple de liaison qui sature. Le taux de packets perdus atteint plus de 20%!:o
Rappel: en ingénierie réseau, on considère qu'une liaison est sous dimensionnée quand elle est utilisée à plus de 80%. Ici, c'est plus de 110% qui voudraient bien passer par le lien.
Et on voit bien par un traceroute que cette saturation est due à une limitation de débit sur un routeur de Pau. C'est bien un problème de dimensionnement de la liaison Pau-Paris.
Quand la liaison ne sature pas, le ping est à peu près de 15ms, cohérent avec la distance Pau-Paris (- de 800km). C'est d'ailleurs le Ping Paris-Pau constamment observé sur le réseau Free avec la même méthode.

Ce constat explique grandement l'impossibilité de jouer en réseau (très sensible à la perte de packets), et toutes les applications temps réel (visio, tel). Si vous voulez jouer, je vous conseille entre 4h et 9h du mat!
Cela explique également les surfs lents, car les retransmissions doivent être très nombreuses. Bref, si j'étai vous, je gueulerai (monter une pétition, autre), car là c'est assez inacceptable comme prestation.
Je pense que ce genre de problèmes était largement prévisible: L'upload proposé par les FAI de Pau Broadband Country est largement trop élevé pour une offre pérenne à ce prix. Surtout que le projet ne rencontre pas, aujourd'hui, le succès escompté. Qu'en serait-il s'il y avait 10 fois plus de connectés, comme espéré?
Je ne comprend pas que vous parliez d'abus pour ce genre de comportement: l'upload proposé ne serait pas fait pour être utilisé? L'upload est aujourd'hui l'un des seuls arguments valables pour le FTTH en comparaison de l'ADSL pour les zones urbaines denses.

Sur ce, je vous souhaite bien du courrage.

Leon.

Leon, tu utilisesque outil pour faire ces graph ?

J'ai essayé de grapher les pertes de paquet avec IPERF (en UDP). Le problème est qu'IPERF mesure les perte dans chaque sens. Le problème est que le rapport distant n'arrive pas si il y a trop de pertes de paquets donc on n connait pas le résultat si il y a trop de pertes. Donc c'est une solution pour les liaisons avec peu de pertes, pas pour Neuf Pau.[/size]

Leon · « **Réponse #15 le:** 02 décembre 2007 à 10:32:10 »

Citation de: vivien le 02 décembre 2007 à 09:54:33

Leon, tu utilisesque outil pour faire ces graph ?

A l'époque, j'utilisais un petit logiciel basique "packloss" sous windows. Le graphe est simplement réalisé sous excel à partir des logs du logiciel.

http://packloss.free.fr/

Leon.

vivien · « **Réponse #16 le:** 02 décembre 2007 à 11:28:53 »

C'est disponible uniquement sous windows...

J'ai eu une idée. Lors de mes test de débit en TCP qui servent à générer les graph de déits, je vais démarrer simultanèment un dump sur l'IP et le port du testeur. A la fin je post-trate avec http://www.tcptrace.org/ pour récupérer le nb de paquets perdu.

Cela permet d'avoir le taux de perte non pas en ICMP mais en TCP sur des gros paquets.

Cela permet aussi de séparer perte en upload et pertes en download.

willemijns · « **Réponse #17 le:** 02 décembre 2007 à 15:43:01 »

Citation de: vivien le 01 décembre 2007 à 09:39:19

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

ok mais alors ou peut se faire cette perte de paquet en FTTH (liaison 100% numérique de bout en bout) ?

vivien · « **Réponse #18 le:** 02 décembre 2007 à 22:53:04 »

Les pertes de paquet me laissent perplexe ce soir.

Voici le résultat d'iperf qui devrais durer 6 secondes dans chaque sens en TCP :

Code: [Sélectionner]

[  6] local 213.251.129.x port 4865 connected with 77.199.255.x port 5002
[  6]  0.0- 3.0 sec  16.5 MBytes  46.1 Mbits/sec
[  6]  3.0- 6.0 sec  0.00 MBytes  0.00 Mbits/sec
[  6]  0.0- 7.7 sec  16.5 MBytes  17.9 Mbits/sec
[  6] MSS size 1448 bytes (MTU 1500 bytes, ethernet)
[  5] local 213.251.129.x port 5002 connected with 77.199.255.x port 48388
[  5]  0.0- 3.0 sec  20.0 MBytes  55.9 Mbits/sec
[  5]  3.0- 6.0 sec  19.4 MBytes  54.4 Mbits/sec
[  5]  6.0- 9.0 sec  0.07 MBytes  0.19 Mbits/sec
[  5]  0.0-10.7 sec  39.5 MBytes  31.0 Mbits/sec
[  5] MSS size 1448 bytes (MTU 1500 bytes, ethernet)

Les paquets arrivent avec 1,7 seconde de retard dans le sens Paris => Pau
Dans l'autre sens c'est 4,7 secondes.

feyb64 · « **Réponse #19 le:** 03 décembre 2007 à 01:01:25 »

La seule chose que je vois c'est qu'il y a plutôt des pertes et pas des 'retards' et comme test en 'tcp', retransmissions d'où 'retards' au final.

Seul un dump tcp pourra indiquer ce qui se passe (qui par exemple indique une erreur via d'éventuels paquets icmp à la source)

feyb64 · « **Réponse #20 le:** 03 décembre 2007 à 01:13:21 »

Citation de: leon_m le 02 décembre 2007 à 09:23:42

Tout cela me rappelle la situation d'il y a 2 ans sur le PBC, avec la montée en puissance d'IPVSET.

Au fond, les problèmes n'ont pas beaucoup changés. Il faudrait un peu plus d'explication de la part des "autorités" du PBC, parce que là, un problème d'il y a 2 ans qui ressurgit, ça n'est pas très normal.

Leon.

Sans vouloir atténuer le problème présent, ce n'est pas tout à fait le même scénario, sagissant ici d'un pb vraiment très ponctuel et très court à une heure assez bien définie (21h environ) et tous les jours ou presque (quelques fois c'est minime).
Je ne pense pas que l'on soit à ce moment là un niveau de saturation du lien (je ne l'élimine pas pour autant) mais à un pb de matos sur la 'route' qui fait quelque chose de 'particulier' à cette heure (maj ? flushs mémoires ? reload config ? test de basculement liens de fail over ? ...) et qui perturbe le débit max atteignable le temps de 'retrouver ses petits' (Reste à savoir 'qui' et 'pourquoi' si c'est ça).

vivien · « **Réponse #21 le:** 03 décembre 2007 à 07:06:57 »

Citation de: feyb64 le 03 décembre 2007 à 01:01:25

La seule chose que je vois c'est qu'il y a plutôt des pertes et pas des 'retards' et comme test en 'tcp', retransmissions d'où 'retards' au final.

Bien sur ce sont des pertes qui entraînes re-transmission et re-re-transmission. La gigue (retard d'un paquet par rapport à un autre) ne peut dépasser quelques ms sur ce type de réseau.

willemijns · « **Réponse #22 le:** 03 décembre 2007 à 19:03:45 »

Citation de: feyb64 le 03 décembre 2007 à 01:13:21

Je ne pense pas que l'on soit à ce moment là un niveau de saturation du lien (je ne l'élimine pas pour autant) mais à un pb de matos sur la 'route' qui fait quelque chose de 'particulier' à cette heure (maj ? flushs mémoires ? reload config ? test de basculement liens de fail over ? ...) et qui perturbe le débit max atteignable le temps de 'retrouver ses petits' (Reste à savoir 'qui' et 'pourquoi' si c'est ça).

il faudrait prolonger les tests sur plusieurs minutes alors...

vivien · « **Réponse #23 le:** 03 décembre 2007 à 19:26:22 »

La perturbation dure de 2 à 3h en général. (tests manuels effectués en //)

Auteur Sujet: 2007 : pourquoi des mauvais débits vers 21h chaque jour en download ? (Lu 17796 fois)

feyb64

Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?

Leon

Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?

vivien

Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?

Leon

Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?

vivien

Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?

willemijns

Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?

vivien

Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?

feyb64

Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?

feyb64

Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?

vivien

Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?

willemijns

Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?

vivien

Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?