La Fibre

Forum : => Pyrénées-Atlantiques (64) => La Fibre par département => Incidents Pau Broadband Country => Discussion démarrée par: vivien le 28 novembre 2007 à 23:21:11

Titre: 2007 : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: vivien le 28 novembre 2007 à 23:21:11
pourquoi des mauvais débits vers 21h chaque jour en download ?

(https://lafibre.info/images/altice/neuf28nov2007.png)

Le phénomène semble cyclique.

Vivien.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: lepalois le 28 novembre 2007 à 23:27:35
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.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: feyb64 le 29 novembre 2007 à 00:35:53
Peut être le phénomène simple de 'plein de machines allumées' à ces heures (aux environs de fin de repas) et provoquant de fortes demandes simultanées.
Une possibilité lors de ces 'allumages' : beaucoup de softs installent leur 'auto-update' se chargeant alors au démarrage ou ouverture de session (malgrés nous sans proposer de ne pas l'activer à l'install mais 'quand je veux manuellement le faire).
Les plus gros 'mangeurs' sont les anti-virus qui très régulièrement ont des maj des bases de virus même minime mais 'on recharge la totalité (pas de mode 'incrèmentiel')
Sans comptes les mules et autres qui sont configurés pour démarrer aussi sec le pc allumé, provoquant d'innombrables connexions et transferts de toutes sortes (état des téléchargements, listes des 'offreurs', ....)

A part ce genre de 'trucs' côté clients, je ne vois pas quelle partie du réseau peut provoquer ce phénomène si régulier et de durée relativement courte d'après les graphes.
Mais il faudrait peut être pousser le nombre de tests par heure pendant cette période pour avoir plus de détail sur sa durée ou uniquement des pics pendant cette période. du style tous les 1/4 d'heure pour commencer.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: vivien le 29 novembre 2007 à 21:18:33
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.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: feyb64 le 29 novembre 2007 à 22:20:45
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 ?
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: vivien le 29 novembre 2007 à 22:27:11
Citation de: feyb64 le 29 novembre 2007 à 22:20:45
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à)
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: willemijns le 30 novembre 2007 à 14:28:00
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  :P :o ;D ;D ;D ;D ;D
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: feyb64 le 30 novembre 2007 à 22:24:51
Citation de: willemijns le 30 novembre 2007 à 14:28:00
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  :P :o ;D ;D ;D ;D ;D

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.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: willemijns le 30 novembre 2007 à 22:56:29
disons que moi c'est l'effet mathematique qui m'a laissé perplexe... des pertes ok mézou...
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: 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 :
 
(https://lafibre.info/images/wireshark/formule-perte-paquets.png)

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 (https://lafibre.info/images/tuto/debit-max-tcp.html) (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 (https://lafibre.info/images/tuto/debit-max-tcp.html)
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: feyb64 le 01 décembre 2007 à 15:26:31
La formule mathématique est certes bonne mais la réalité est tout autre chose  ::)

Si on applique cette formule, pour obtenir les 50Mb/s max d'après ton tableau il faut avoir maximum 0.001% de perte soit dix fois moins encore que ton 'maximum acceptable' ce n'est pas 0.01% ! au pire 0.002% :

MSS (en octets) 1460
RTT de 40ms
paquets perdusDébit max en Kb/s
0,001%64 637
0,002%45 705
......
0,01%20 440
Peut être cela est il possible en intra pbc, mais en liaison avec Internet j'en doute, même pour ton 0,01% ...

D'ailleurs, une question à 0€ : sur quel(s) critère(s) choisies tu ce 0,01% 'acceptable' ? 20Mb/s 'acceptable' ? pourquoi devrais je considérer ce débit 'acceptable' quand on me vend du 50Mb/s max possible, certe sans garantie.
Mais justement à partir de quel pourcentage de disponibilité de ce 50Mb/s doit on considérer que c'est 'acceptable' ?
10%, 20%, 50%, 75%, 90% 100% ?

Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: 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.).

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 (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.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: feyb64 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.

Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: Leon 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.
(https://lafibre.info/images/pau/pbc_mars_2006_1.png)
http://vers la machine précédente, il ya aussi une perte de paquets... minime mais existante

(https://lafibre.info/images/pau/pbc_mars_2006_2.png)


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.
(https://lafibre.info/images/pau/Ping_PBC.gif)

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 (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 ! :/ :?  :o  :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  :o :o
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.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: vivien 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.
(https://lafibre.info/images/pau/Ping_PBC.gif)
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]
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: Leon 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.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: vivien 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.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: willemijns 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) ?
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: vivien 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.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: 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.

Seul un dump tcp pourra indiquer ce qui se passe (qui par exemple indique une erreur via d'éventuels paquets icmp à la source)
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: feyb64 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).
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: vivien 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.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: willemijns 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...
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: vivien le 03 décembre 2007 à 19:26:22
La perturbation dure de 2 à 3h en général. (tests manuels effectués en //)
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: aures64 le 03 décembre 2007 à 21:21:47
Les débits en FTP sont bas chez moi à ces heures-ci.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: feyb64 le 03 décembre 2007 à 21:24:45
Citation de: vivien le 03 décembre 2007 à 19:26:22
La perturbation dure de 2 à 3h en général. (tests manuels effectués en //)

Peut être mais :
1 - ce que montrent tes graphes c'est uniquement avec des tests toutes les heures sur une plage qui va de 19h à 23h soit 3 points de test dans la plage 'critique' (20h, 21h, 22h), pas 'terrible' comme résolution pour déterminer quoi que ce soit d'utile si ce n'est 'baisse' significative à 21h
2 - de ce fait est ce permanent pendant ces 2-3 heures ou par pics dans cette plage horaire ?

Comme le dit Willemijns, il faudrait prolonger la durée de chaque test individuel et en faire plus régulièrement dans cette plage horaire pour étudier plus finement les perturbations.
Dans un premier temps des tests toutes les 1/4 heures de 1mn à 2 mn de 19h à 23h par exemple, au moins pour donner une idée un peu plus précise. Avec plusieurs jours comme cela, un graphe global avec une courbe par jours représenté pourra aidé à savoir si perturbation 'constants' dans la durée (les 3 heures), identique tous les jours ou presque, ou pas du tout, par pics et si par pics, toujours ces pics dans les mêmes plages horaires ou répartis aléatoirement par jours, ...

Ensuite si cela ne suffit pas encore des tests plus fins en choisissant dans les 19h-23h les plages plus petites qui semblent régulièrement les plus perturbées que les autres et tests sur ces plages toutes les 5mn de 1 à 3mn et encore un graphe avec chaque mesures journalières représentées individuellement.

il faudrait aussi ces même tests en tcp ET udp afin de voir les différences possibles.

Sans ce genre de 'tests', point de polémique/palabres/hypothèses à créer en ce qui concerne qui, quoi, où, pourquoi  :)
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: vivien le 03 décembre 2007 à 21:51:23
Pas facile de modifier la représentation sur le graph vu que je lui demande de prendre le débit max de l'heure.
(on ne peut pas changer en 1/4 d'heure facilement)

Au niveau des test on peut en faire + mais je m'explique :

Ce soir les débits on commencé a chuter à partir de 20h.
Si c'étais une courbe moyenne on le verrais mieux.

voici les 2 mesures de 20h :

2007-12-03 20:02:24     56.3     17.1     16.587
2007-12-03 20:03:14    4.71    41.7    15.826

20h02 : upload 56 Mb/s    download :  17 Mb/s
20h03 : upload 4 Mb/s     download : 41 Mb/s

Le graphe affiche : upload 56 Mb/s    download : 41 Mb/s
pour toi tout est normal or ce n'est pas le cas.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: feyb64 le 03 décembre 2007 à 22:08:53
Citation de: vivien le 03 décembre 2007 à 21:51:23
Pas facile de modifier la représentation sur le graph vu que je lui demande de prendre le débit max de l'heure.
(on ne peut pas changer en 1/4 d'heure facilement)

Au niveau des test on peut en faire + mais je m'explique :

Ce soir les débits on commencé a chuter à partir de 20h.
Si c'étais une courbe moyenne on le verrais mieux.

voici les 2 mesures de 20h :

2007-12-03 20:02:24     56.3     17.1     16.587
2007-12-03 20:03:14    4.71    41.7    15.826

20h02 : upload 56 Mb/s    download :  17 Mb/s
20h03 : upload 4 Mb/s     download : 41 Mb/s

Le graphe affiche : upload 56 Mb/s    download : 41 Mb/s
pour toi tout est normal or ce n'est pas le cas.

Donc ton graphe est un vilain menteur ;D
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: vivien le 03 décembre 2007 à 22:21:50
Prendre la valueur max permet de ne montrer que les pb réseaux, de ne pas prendre en compte les téléchargements...

C'est un choix. cela à ses avantages (cela permet mieux de discerner un pb) et inconvenants (atténuation des pb).
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: vivien le 04 décembre 2007 à 22:25:30
Voici la dernière courbe crée.
Elle est mis à jour tous les soir vers 23h10.

(https://lafibre.info/iperfpng/courbes_annee_neuf50_ping.png)

Elle reprend le ping moyen maximum de la journée.

Il me semble que les jour a fort ping sont ceux où il y a des problèmes de TV.
Titre: Neuf Pau : pourquoi des mauvais débits vers 21h chaque jour en download ?
Posté par: willemijns le 05 décembre 2007 à 12:32:37
Citation de: vivien le 03 décembre 2007 à 22:21:50
Prendre la valueur max permet de ne montrer que les pb réseaux, de ne pas prendre en compte les téléchargements...
C'est un choix. cela à ses avantages (cela permet mieux de discerner un pb) et inconvenants (atténuation des pb).

on peut rermarquer qu'hier point de problemes, maintenant mon speedtest avec son nombre
impressionnant de serveurs FTP permet en quelques jours de detecter les liaisons qui flanchent
mais bon avec le  concept monothread de vivien on ne sait que ca flanche sur une partie
ou la totalité de la liaison...