La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => SFR / RED => 
Incidents SFR => Discussion démarrée par: amna le 27 octobre 2022 à 12:47:53
-
Hello, je suis sous red sfr depuis quelques années sur Saint-Ouen, j'ai remarqué recemment une chute quotidienne entre 21h et 23h ci-joint le graph.
Le download seul semble affecté, mais j'ai déjà eu une soirée avec 1seconde constante de ping sur toutes les ips externes.
Serait-ce un bridage une collecte? quelles sont mes actions?
Merci d'avance!
-
Ca ressemble à une saturation de la collecte.
-
Faut arrêter avec le terme bridage à tout va...
-
noté 👍 ;D
-
Faut arrêter avec le terme bridage à tout va...
Pas d'upgrade volontaire de la collecte = bridage :P
-
Salut,
ci-joint le graph.
Question anecdotique : avec quel outil produis-tu ces graphiques intéressants ?
À+
-
J'ai le même problème entre 21h et ~23h, ping qui monte, débit qui chute...J'ai appelé et ils proposent de m'envoyer une nouvelle box.
(https://i.imgur.com/DXWyoly.png)
-
Il faut qu'on m'explique comment une autre box peut "désaturer" une collecte. Ça en dit long sur les connaissances de ces superbes hotlines :(
-
Hélas... Comme tu dis...
Bien souvent ces SC délocalisés "tentent des trucs", en mode "ça marchera p'tet, sur un malentendu...".
Et encore, là c'est à la lueur d'un "diagnostic technique". On ne compte plus les cas où (bien que ce soit documenté depuis avril 2019) ce service client a envoyé, en pure perte et sans être utilisable, un disque dur aux clients qui se plaignaient de ne pas en avoir reçu... C'est déroutant d'an arriver à un tel bricolage d'amateurisme...
À+
-
Ou simplement l"objectif étant de fournir une réponse/action afin que l'abonné termine l'appel satisfait, même si le problème ne sera pas solutionné par cette réponse/action...
Au final on peut constater que les connexions internet c'ets toujours le même cirque depuis plus de 20 ans, toujours sans aucune obligation de résultat pour les FAIs pffff
-
Ou simplement l"objectif étant de fournir une réponse/action afin que l'abonné termine l'appel satisfait, même si le problème ne sera pas solutionné par cette réponse/action...
Oui, ils "tentent des trucs" à mon sens comme je l'écrivais juste avant.
D'ailleurs ça reste sans doute non rentable : une box envoyée pour rien, et le client qui reviendra sûrement. J'imagine que les managers ont des indicateurs pour mesurer ça...
toujours sans aucune obligation de résultat pour les FAIs pffff
Je me demande toujours si les FAI n'ont vraiment aucune obligation de résultat, ou s'ils sont hors-la-loi en ne s'en imposant aucune contractuellement. À la lecture de cet ancien article on pourrait croire que la loi dit le contraire d'après cet extrait :
L'association de consommateurs a ainsi réussi à faire valoir que l'absence de garantie concernant les débits ou le délai de transmission des messages était illicite en vertu d'un arrêté de 2006 imposant aux opérateurs de faire apparaître dans leurs contrats « le niveau de qualité minimum garanti pour chacune des caractéristiques techniques essentielles définies dans l’offre, telles que le débit ».
-
Des beaux textes leurs trucs mais sur le terrain c'est toujours l'abonné qui se retrouve le bec dans l'eau (et je m'y connais, en tant que couin couin).
-
Je me demande toujours si les FAI n'ont vraiment aucune obligation de résultat, ou s'ils sont hors-la-loi en ne s'en imposant aucune contractuellement. À la lecture de cet ancien article on pourrait croire que la loi dit le contraire d'après cet extrait :
Cela existe. Dans mes CGVs Free, j'ai comme information pour les débits :
- pour la fibre entre 128 kbit/s et 1 Gbit/s ou 8 Gbit/s selon l’offre souscrite par l’abonné et la Freebox compatible. Débit théorique montant maximum jusqu’à 600 Mbit/s.
Donc le débit minimum est de 128 kb/s. Tu peux te plaindre si ton débit fibre est en dessous de cette valeur. Gros engagement !
-
Ils pouvaient mettre entre 1 kbit/s et 1 Gbit/s ou 8 Gbit/s directement hein ... Les Arcep ou je ne sais qui, laissent faire ça ? Ah bah top.
-
Les Arcep ou je ne sais qui, laissent faire ça ? Ah bah top.
Pour 15-35 euros par mois (TVA incluse), difficile d'offrir une connexion multi-Gb avec des garanties de débit... ca ne payerai même pas le prix du transit pour un abonné qui utilise sa connexion à 1Gbit/s.
Les graphes d'amna sont beaux et montrent bien l'étendue du problème, mais une fois le souci constaté et exposé, il serait bon de désactiver les tests de débit périodiques qui accentuent encore plus les effets de la congestion (pour l'abonné en question comme pour les autres).
N'hésitez pas à changer d'opérateur si cette congestion impacte négativement vos usages.
-
Salut,
Rah la vache, vous vous êtes ligués pour réinventer l'orthographe française : des FAIs, des CGVs, ça pique (https://fr.wikipedia.org/wiki/Sigle) ! :o
Bon trève de plaisanterie (ou en fait continuons dans la plaisanterie)
Donc le débit minimum est de 128 kb/s. Tu peux te plaindre si ton débit fibre est en dessous de cette valeur. Gros engagement !
Ils pouvaient mettre entre 1 kbit/s et 1 Gbit/s ou 8 Gbit/s directement hein ... Les Arcep ou je ne sais qui, laissent faire ça ? Ah bah top.
Ah ah, oui les FAI "peuvent" mettre une garantie minimum de clowns.
J'avais vérifié chez SFR, il y a un minimum donné pour l'ADSL, mais pas du tout pour la fibre (reste à connaître Orange et Bouygues alors).
Je me demandais si un opérateur fibre oserait jouer à ce jeu d'exprimer noir sur blanc dans ses CGV un minimum aussi comique, Free l'a fait, chapeau !
Ils garantiraient ainsi encore moins en fibre que SFR en ADSL :
Pour l’ADSL et le VDSL, débit descendant minimum garanti de 512 Kb/s.
J'avais tendance à croire :
- que les FAI français ne l'écrivaient pas pour la fibre
- que l'Arcep laissait faire, et qu'aucune asso de consommateurs ne les avait fait condamner pour ça
- mais que le jour où l'un deux jouerait au malin à écrire un chiffre aussi bas il serait la risée des forums
- et je me disais même naïvement, que ça deviendrait potentiellement un argument de vente sur la qualité (avantage à celui qui garantit 100 Mbit/s par rapport à celui qui garantit 128 kbit/s par exemple)
La preuve que non ! ;D
Ah, il m'épatent de toupet tout de même, très forts. (Bah comme dirait l'autre, c'est autorisé par la loi, ils auraient tort de se priver).
À+
-
Pour 15-35 euros par mois (TVA incluse), difficile d'offrir une connexion multi-Gb avec des garanties de débit... ca ne payerai même pas le prix du transit pour un abonné qui utilise sa connexion à 1Gbit/s.
Il ne s'agit pas de garantir que le MAXIMUM sera atteint... Mais une valeur MINIMUM (et tant qu'à faire, décente ;))
Si ce n'est pas possible, Orange l'a pourtant fait (avec des minima plus que décents) pendant des années (jusqu'à fin septembre / début octobre 2018) :
- observez les valeurs promises sans bémols
- puis transition (se sentant sans doute le dindon de la farce alors que les concurrents jouaient allègrement du "jusqu'à 1 Gbit/s" écrivant donc des chiffres 2 fois plus gros que Orange...) ils ont fait comme les copains.
cf. les 2 images jointes (extraites des archives du 10/08/2018 (https://web.archive.org/web/20180810120320/https://boutique.orange.fr/internet/offres-fibre), et du 01/12/2018 (https://web.archive.org/web/20181201121320/https://boutique.orange.fr/internet/offres-fibre))
N.B. Toutes les pages archivées ne sont pas aussi lisibles, mais sur celle-ci de septembre 2018 on retrouve bien explicité l'engagement sur "Jet Fibre" :
Internet avec la Fibre
- 500 Mbit/s minimum en débit descendant
- 200 Mbit/s minimum en débit montant
Autre temps, autres mœurs ! 8)
-
Personnellement, j'ai toujours pris ces débits "minimum" comme des engagements sur la synchronisation, pas sur les débits réels :
- Le 512k de SFR en ADSL correspond à la synchro mini qu'ils s'engagent à proposer
- En fibre, ils proposent la "synchro" et sont engagés dessus, il n'y a pas de variabilité comme en ADSL.
- Pour Orange je le vois comme ça aussi.
De toute manière, hormis les offres ultra-chères avec fibres dédiées et débits garantis, il est impossible de garantir un débit minimum décent pour une ville. Une collecte 10Gb pour une ville avec 10000 abonnés pourrait potentiellement ne fournir que 1Mb à chacun si tout le monde s'amuse à faire un speedtest au même moment (et ce n'est qu'à l'échelle d'une ville moyenne)
-
- En fibre, ils proposent la "synchro" et sont engagés dessus, il n'y a pas de variabilité comme en ADSL.
- Pour Orange je le vois comme ça aussi.
Orange avait écrit "débit minimum" dans la page web pour sa fibre dont j'ai donné l'archive.
Tu le lis à ta façon et tu as bien le droit.
Pour un juge, en cas de contentieux, il est clair que si Orange développe ton argumentaire ils seraient évidemment désavoués, notamment pour publicité mensongère. On ne peut pas pousser la mauvaise foi publicitaire à ce point via un artifice technique où débit minimum ne veut plus dire débit minimum ;D
Pour le reste, on ne le saura jamais puisque c'est une époque révolue : ils l'ont retiré de leur offre publicitaire.
De toute manière, hormis les offres ultra-chères avec fibres dédiées et débits garantis
Tu te trompes d'objectif.
Il ne s'agit pas ici d'avoir la totale certitude que ça n'arrivera jamais d'être en dessous en pratique (la vie réelle reste la vie réelle).
C'est un engagement du fournisseur qui donc, s'il n'est pas rempli, permet au client de contester et quitter son offre (sans frais en droit français) puisque le contrat n'est pas assuré.
C'est tout et c'est donc parfaitement contractualisable, même sur du FttH grand public. C'est juste que le fournisseur s'engage un peu plus, et risque un peu plus que des clients le quittent... Ça fait aussi partie de la relation de confiance que de se mouiller un peu plus...
Une collecte 10Gb pour une ville avec 10000 abonnés pourrait potentiellement ne fournir que 1Mb à chacun si tout le monde s'amuse à faire un speedtest au même moment (et ce n'est qu'à l'échelle d'une ville moyenne)
Alors là tu prêches un convaincu.
Tu retrouverais sans peine plusieurs fois où j'ai évoqué ici que vendre 64 abonnements gigabit en FttH Gpon (https://lafibre.info/ftth-la-fibre-optique-gpon-ou-p2p/techno-fibre/) sur une seule fibre de 2,5 Gbit/s, c'était un peu beaucoup camoufler sous le tapis le principe de partage de ressource dont peu de clients étaient vraiment conscients car pas informés là-dessus.
À+
-
Orange avait écrit "débit minimum" dans la page web pour sa fibre dont j'ai donné l'archive.
Tu le lis à ta façon et tu as bien le droit.
Pour un juge, en cas de contentieux, il est clair que si Orange développe ton argumentaire ils seraient évidemment désavoués, notamment pour publicité mensongère. On ne peut pas pousser la mauvaise foi publicitaire à ce point via un artifice technique où débit minimum ne veut plus dire débit minimum ;D
Pour le reste, on ne le saura jamais puisque c'est une époque révolue : ils l'ont retiré de leur offre publicitaire.
Tu te trompes d'objectif.
Il ne s'agit pas ici d'avoir la totale certitude que ça n'arrivera jamais d'être en dessous en pratique (la vie réelle reste la vie réelle).
C'est un engagement du fournisseur qui donc, s'il n'est pas rempli, permet au client de contester et quitter son offre (sans frais en droit français) puisque le contrat n'est pas assuré.
C'est tout et c'est donc parfaitement contractualisable, même sur du FttH grand public. C'est juste que le fournisseur s'engage un peu plus, et risque un peu plus que des clients le quittent... Ça fait aussi partie de la relation de confiance que de se mouiller un peu plus...
Alors là tu prêches un convaincu.
Tu retrouverais sans peine plusieurs fois où j'ai évoqué ici que vendre 64 abonnements gigabit en FttH Gpon (https://lafibre.info/ftth-la-fibre-optique-gpon-ou-p2p/techno-fibre/) sur une seule fibre de 2,5 Gbit/s, c'était un peu beaucoup camoufler sous le tapis le principe de partage de ressource dont peu de clients étaient vraiment conscients car pas informés là-dessus.
À+
Je donnais mon interprétation. Après comme tu le dis, ils ont peut-être eu leur service juridique qui les a alerté sur la portée réelle de ce qu'ils avaient écrit.
Pour la collecte sur l'arbre GPON, ça me rappelle au début Free qui se vantait de sa fibre P2P, en parlant de fibre dédiée, sans indiquer qu'ils avaient une collecte 1Gb derrière :D
-
Je donnais mon interprétation. Après comme tu le dis, ils ont peut-être eu leur service juridique qui les a alerté sur la portée réelle de ce qu'ils avaient écrit.
Pour la collecte sur l'arbre GPON, ça me rappelle au début Free qui se vantait de sa fibre P2P, en parlant de fibre dédiée, sans indiquer qu'ils avaient une collecte 1Gb derrière :D
Totalement faux...
-
Sans surprise, le changement de box ne change rien au fait que le service chez Red By SFR reste médiocre:
(https://i.imgur.com/ujhZIRe.png)
(https://i.imgur.com/V4OLMIQ.png)
-
Sans surprise, le changement de box ne change rien au fait que le service chez Red By SFR reste médiocre:
Perso, je serai parti même avec le double...
Pourquoi tu ne changes pas de FAI ?
-
J'ai fini par en avoir marre de Red By SFR. De retour chez Free et ça marche beaucoup mieux:
(https://i.imgur.com/FCcXGTo.png)
-
Par curiosité as tu essayé Orange ? Comment sont tes débits en soirée ?
-
Bonjour,
Eh bien apres l'arrivee de la fibre en janvier, ravi de ma delta mais voila que dorenavant, tous les soirs, je ne peu plus rien faire
ni jouer en cloud ni telecharger quoi que ce soit que ce soit sur console de jeu ou sur le pc en wifi6 ou ethernet , ni mm regarde une video sans saccade.
tout redevient normal vers 23h
la degradation commence vers 20h30
bien entendu free me repond RAS
je souhaterais savoir ce qui provoque ce phenomene, sachant que un voisin sur le mm NRO que moi ne rencontre pas ces problemes
un copain habitant a 40km de la avec la mm configuration que moi lui rencontre aussi les mm problematique
free c'est devenu juste bon pour regarde la tv??
-
Attention, tu es dans la section SFR ici, pas Free.
Après ça ressemble fortement à une saturation sur le réseau Free, pour autant c'est bizarre que vous soyez 2 sur 3 impacté comme cela.
-
Ah désolé ;)
Merci
Free ou sfr mm combat semble t’il :(
-
Bonjour à tous,
Je suis fibré RED avec une offre 1G/700M dans les Boûches-du-Rhône.
Je constate le même phénomène problématique depuis vendredi soir 17 mars dernier.
Le débit descendant chute de 300 Mbit/s la nuit à 30 Mbit/s les journées, puis à 3 Mbit/s les soirs.
Le débit montant est stable sans souci à 300 Mbit/s tout le temps.
Intensité signal toujours à -21 dBm reçue et +4 dBm transmise.
Je vais contacter le Service Client RED via mon espace client sur application mobile en laissant un message sur tchat après lancement du Diagnostic auto-bot.
Voici mon tableau de débit tracé et captures en preuve à l'appui :
(https://i.ibb.co/hCK3VQW/tableaudebits.png) (https://i.ibb.co/1b9FTyq/tableaudebits.png)
(https://i.ibb.co/9bB0Gdc/allss.png) (https://i.ibb.co/Cb4yWSm/allss.png)
Je suis preneur de vos partages d'expérience similaire et si vous sauriez l'origine du problème et son moyen de résolution.
Je vous remercie ! Bonne journée à tous
-
Bonjour j'ai exactement le même problème sur ma ligne fibre sfr et vu la ville indiqué sur tes speedtest je suis dans la même zone géographique donc surement impacté par le même problème que toi
depuis vendredi dernier 12h chute progressive du debit l'apres midi et le soir il ne reste qu'un petit mbps, augmentation du ping d'environ 30-35ms dès le 3eme saut sur un tracert sur l'ip 77.136.89.102 dans le sens sortant et meme chose sur l'ip 77.136.89.101 en entrant (l'avant dernier saut) avec en prime jusqu'à 25-30% de paquets perdus
Détermination de l’itinéraire vers one.one.one.one [1.1.1.1]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms box [192.168.1.1]
2 1 ms 1 ms 1 ms 1.224.139.88.rev.sfr.net [88.139.224.1]
3 39 ms 39 ms * 102.89.136.77.rev.sfr.net [77.136.89.102]
4 49 ms 50 ms * 221.10.136.77.rev.sfr.net [77.136.10.221]
5 49 ms 49 ms 49 ms 221.10.136.77.rev.sfr.net [77.136.10.221]
6 50 ms 50 ms * 141.101.67.254
7 50 ms 49 ms * 141.101.67.52
8 49 ms 49 ms 49 ms one.one.one.one [1.1.1.1]
Itinéraire déterminé.
j'ai ajouté 2 images de speedtest vers le serveur sfr a paris a 19h30 et a 2h30
sur l'outil drakkar de sfr il y a que message qui a été remonté dimanche mais qui a été fermé hier (lundi), bien sur probleme non résolu pour autant
"statut":"FERME","date_debut":"2023-03-19 12:21:55","date_cloture":"2023-03-21 05:20:22","equipements":[{"type_equ":"GPON","nom_equ":"13sau2-gp-01","univers":"FTTH"},{"type_equ":"NRO","nom_equ":"13ane1-nro-2","univers":"FTTH"
-
Bonjour,
Merci pour votre partage d'expérience Comancheiv ce qui me reconforte car mettant de côté un problème de ligne individuel et physique unitaire.
J'ai néanmoins contacté le SAV de RED Mardi 21 mars à 14h00 pour avoir une visibilité.
Pour cela, j'ai utilisé le tchat bot sur l'application sur mobile qui m'a déclenché un appel instantané de mise en relation avec un conseiller.
J'étais surpris car je suis abonné RED depuis plus de 2 mois et croyais être limité à une conversation écrite au delà de 2 mois d'abonnement.
Le conseiller a pris note du baisse de débit et m'a fait reseter la box wifi (avec cur-dent pour le bouton) pour une mise en surveillance de la ligne de bout en bout ce durant 24 heures et m'a proposé un rdv téléphonique pour un bilan au lendemain, le Mercredi 22 mars à 13h30.
Dans la matinée du Mercredi, un SMS m'a informé de l'implication des techniciens oeuvrant pour la résolution du problème.
A midi, sur ma page de suivi SAV je voyais l'évolution du statut avec la mention de motif "incident générique en cours de résolution par nos techniciens".
J'étais en relation avec un conseiller l'après-midi comme convenu et qui m'a informé d'un problème sectoriel, et qui sera résolu prochainement avec date prévisionelle au 1er Avril après-midi avec réception SMS de signalement de résolution.
Le conseiller m'a proposé un geste de régularisation par remboursement par jour d'incident et m'a aussi proposé une clé de connexion par réseau mobile de secours.
J'étais surpris par ces dispositions de la part d'un fournisseur low-cost pourtant et qu'on crache énormément sur Internet sur sa réputation.
J'ai ensuite reçu un SMS en fin d'après-midi confirmant l'anomalie réseau dans le quartier suivi d'un autre sms confirmant la prise en compte de la demande de remboursement initié par le conseiller RED.
Sinon, je constate que j'ai récupéré hier soir même le débit descendant rétabli à plus de 500 Méga pour information.
-
Pareil ici dans le nord chez red by SFR :
perte de paquets le soir et parfois même le midi, cela va jusqu'à la perte total de la ligne.
Je precise que jusqu'ici je n'etais pas trop ennuyé par Red.
ici le retour de pfsense sur la journée du 30/03/2023
Mar 31 14:52:25 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 9537us stddev 650us loss 5%
Mar 31 14:51:27 dpinger 48270 WAN_DHCP 1.1.1.1: sendto error: 65
Mar 31 14:51:26 dpinger 48270 WAN_DHCP 1.1.1.1: sendto error: 65
Mar 31 14:51:26 dpinger 48270 WAN_DHCP 1.1.1.1: sendto error: 65
Mar 31 14:51:25 dpinger 48270 WAN_DHCP 1.1.1.1: sendto error: 65
Mar 31 14:48:56 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 13635us stddev 5046us loss 21%
Mar 31 14:46:47 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 22870us stddev 13154us loss 5%
Mar 31 14:43:28 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 23774us stddev 7774us loss 22%
Mar 30 22:33:59 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66060us stddev 319us loss 19%
Mar 30 22:33:39 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66109us stddev 481us loss 21%
Mar 30 22:30:20 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66130us stddev 461us loss 18%
Mar 30 22:28:58 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66180us stddev 456us loss 21%
Mar 30 22:28:51 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66316us stddev 1405us loss 19%
Mar 30 22:28:23 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66297us stddev 1404us loss 21%
Mar 30 22:21:09 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66740us stddev 1623us loss 16%
Mar 30 22:20:55 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66411us stddev 1381us loss 21%
Mar 30 22:20:50 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66320us stddev 1316us loss 19%
Mar 30 22:20:10 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66210us stddev 542us loss 21%
Mar 30 22:19:58 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66161us stddev 424us loss 17%
Mar 30 22:19:32 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66148us stddev 453us loss 21%
Mar 30 22:15:57 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66208us stddev 377us loss 16%
Mar 30 22:15:44 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66193us stddev 453us loss 21%
Mar 30 22:15:30 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66165us stddev 371us loss 17%
Mar 30 22:14:52 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66257us stddev 456us loss 21%
Mar 30 22:14:40 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66268us stddev 477us loss 20%
Mar 30 22:13:21 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66353us stddev 1334us loss 21%
Mar 30 22:10:36 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66251us stddev 462us loss 17%
Mar 30 22:09:41 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66236us stddev 1296us loss 21%
Mar 30 22:05:49 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66264us stddev 1140us loss 17%
Mar 30 22:05:26 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66199us stddev 1168us loss 21%
Mar 30 22:03:35 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66194us stddev 877us loss 18%
Mar 30 22:03:02 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66245us stddev 892us loss 21%
Mar 30 22:02:43 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66198us stddev 379us loss 18%
Mar 30 22:02:31 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66271us stddev 1423us loss 21%
Mar 30 22:02:23 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66276us stddev 1418us loss 20%
Mar 30 22:02:11 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66255us stddev 1450us loss 21%
Mar 30 22:02:08 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66287us stddev 1445us loss 20%
Mar 30 22:01:26 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66455us stddev 1603us loss 21%
Mar 30 22:01:14 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66416us stddev 1576us loss 19%
Mar 30 22:00:59 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66357us stddev 1599us loss 21%
Mar 30 22:00:33 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66403us stddev 1629us loss 19%
Mar 30 21:59:23 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66124us stddev 1043us loss 21%
Mar 30 21:57:22 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66166us stddev 563us loss 15%
Mar 30 21:57:07 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66175us stddev 581us loss 21%
Mar 30 21:56:51 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66141us stddev 453us loss 20%
Mar 30 21:56:32 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66158us stddev 417us loss 21%
Mar 30 21:54:12 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66303us stddev 823us loss 16%
Mar 30 21:53:02 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66249us stddev 524us loss 21%
Mar 30 21:48:38 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66058us stddev 468us loss 17%
Mar 30 21:48:26 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66098us stddev 552us loss 21%
Mar 30 21:48:22 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66119us stddev 551us loss 20%
Mar 30 21:47:34 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66184us stddev 343us loss 21%
Mar 30 21:47:30 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66199us stddev 372us loss 19%
Mar 30 21:47:13 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66208us stddev 388us loss 21%
Mar 30 21:45:11 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66078us stddev 416us loss 16%
Mar 30 21:45:01 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66059us stddev 493us loss 21%
Mar 30 21:44:10 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66067us stddev 544us loss 20%
Mar 30 21:43:02 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66104us stddev 507us loss 22%
Mar 30 21:43:01 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66097us stddev 455us loss 20%
Mar 30 21:41:59 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66166us stddev 1217us loss 21%
Mar 30 21:39:17 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66122us stddev 665us loss 20%
Mar 30 21:37:58 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66199us stddev 1023us loss 21%
Mar 30 21:36:30 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66176us stddev 1278us loss 18%
Mar 30 21:36:20 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66043us stddev 556us loss 21%
Mar 30 21:34:56 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66173us stddev 677us loss 19%
Mar 30 21:34:21 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66075us stddev 602us loss 21%
Mar 30 21:34:17 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 65971us stddev 537us loss 20%
Mar 30 21:33:58 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 65980us stddev 449us loss 21%
Mar 30 21:33:25 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 65957us stddev 458us loss 15%
Mar 30 21:33:10 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 65984us stddev 350us loss 21%
Mar 30 21:32:35 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66002us stddev 393us loss 18%
Mar 30 21:32:17 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 65974us stddev 471us loss 21%
Mar 30 21:31:03 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66145us stddev 418us loss 19%
Mar 30 21:30:45 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66116us stddev 458us loss 21%
Mar 30 21:30:41 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66117us stddev 457us loss 19%
Mar 30 21:29:31 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66044us stddev 446us loss 22%
Mar 30 21:28:08 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 65917us stddev 485us loss 19%
Mar 30 21:27:57 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 65926us stddev 475us loss 21%
Mar 30 21:27:52 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 65935us stddev 378us loss 20%
Mar 30 21:27:31 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66105us stddev 1081us loss 21%
Mar 30 21:24:01 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 65894us stddev 471us loss 16%
Mar 30 21:23:41 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 65976us stddev 401us loss 21%
Mar 30 21:21:32 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66173us stddev 409us loss 19%
Mar 30 21:21:10 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66137us stddev 321us loss 21%
Mar 30 21:20:25 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66040us stddev 361us loss 19%
Mar 30 21:20:15 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66029us stddev 476us loss 21%
Mar 30 21:20:11 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66019us stddev 447us loss 19%
Mar 30 21:19:16 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66056us stddev 733us loss 21%
Mar 30 21:17:47 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 65905us stddev 361us loss 18%
Mar 30 21:17:29 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 65915us stddev 466us loss 21%
Mar 30 21:16:12 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66076us stddev 614us loss 18%
Mar 30 21:13:52 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 65983us stddev 305us loss 21%
Mar 30 21:09:18 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66139us stddev 793us loss 17%
Mar 30 21:08:58 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66256us stddev 1460us loss 22%
Mar 30 21:08:32 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66315us stddev 1375us loss 17%
Mar 30 21:07:08 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66349us stddev 1582us loss 21%
Mar 30 21:04:02 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66394us stddev 1098us loss 18%
Mar 30 21:03:52 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66348us stddev 768us loss 21%
Mar 30 21:02:14 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66392us stddev 1408us loss 17%
Mar 30 21:02:03 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66421us stddev 1494us loss 21%
Mar 30 21:01:45 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66288us stddev 743us loss 19%
Mar 30 21:01:26 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66302us stddev 650us loss 21%
Mar 30 20:59:23 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66340us stddev 683us loss 20%
Mar 30 20:59:03 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66356us stddev 801us loss 21%
Mar 30 20:58:21 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66132us stddev 428us loss 18%
Mar 30 20:58:11 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66113us stddev 362us loss 21%
Mar 30 20:56:33 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66803us stddev 2678us loss 18%
Mar 30 20:56:20 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66734us stddev 2573us loss 21%
Mar 30 20:56:18 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66390us stddev 1674us loss 20%
Mar 30 20:56:01 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66168us stddev 1106us loss 21%
Mar 30 20:54:13 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66097us stddev 377us loss 15%
Mar 30 20:53:39 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66053us stddev 358us loss 21%
Mar 30 20:53:29 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66056us stddev 439us loss 20%
Mar 30 20:53:09 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66234us stddev 782us loss 21%
Mar 30 20:45:02 dpinger 48270 WAN_DHCP 1.1.1.1: Clear latency 66159us stddev 1167us loss 19%
Mar 30 20:44:36 dpinger 48270 WAN_DHCP 1.1.1.1: Alarm latency 66157us stddev 677us loss 21%
Une intervention le 30/04 on dirait :
//Drakkar40/A: OK (1837)
drakF([
{"incident_id":"1024608","reference_ticket":"C30343093","statut":"FERME","date_debut":"2023-03-30 10:50:09","date_cloture":"2023-03-30 11:08:32","equipements":"<count xsi:type="xsd:int">0</count><equipements xsi:nil="true"/>","impact":"7120","commentaire":"Services indisponibles pour les clients raccordés sur l'équipement GPON 62bel1-gp-01 / GPON 62car1-gp-01 / GPON 62dou2-gp-01","defaut":"H.S.","est_crise":"false","affichage_client":"true","discours_id":"E01"},
0])
Mais ça n'a rien changé :)
Ici un screeshot de ma qualité de ligne sur un mois, on voit qu'à partir du 27/03/23 je commence à avoir du packet loss.
-
Ça devrait aller mieux pour ce week-end, à vérifier sur les jours à venir.
-
Ça devrait aller mieux pour ce week-end, à vérifier sur les jours à venir.
Si tu as pu intervenir, c'est super sympa, merci ! C'est confidentiel ou tu peux me dire ce que tu as fait ?
-
Comme dirait Elizabeth : Never explain, never complain ;D
-
Comme dirait Elizabeth : Never explain, never complain ;D
plus de signe de perte de paquets durant cette soirée :) donc une belle amélioration.
Comme dirait Winston "On vit de ce que l’on obtient. On construit sa vie sur ce que l’on donne.”
Merci d'avoir donné de ton temps Floyder
à suivre
-
J'ai un problème similaire dans la ZTD du Cannet dans les Alpes-Maritimes depuis quelques jours.
Très grosse saturation entre 19h30 et 23h30, avec jusqu'à 12% de perte de paquets, une multiplication par 2,5 de la latence et un débit en DL réduit à 10/15Mbps au lieu d'1Gbps en temps normal, tout ce qui est streaming sur Netflix/Disney+ est inutilisable, et même la navigation web est impactée au point que les pages texte chargent lentement.
Ca doit être lié à une route spécifique, parce que si au lieu de faire un nperf vers le nouveau serveur SFR placé à Aubagne qui semble être sur cette route et que je fais un nperf sur le serveur de Venissieux, j'ai des débits pratiquement normaux.
En journée, le DL ne dépasse pas 450Mbits sur la route par défaut, alors que venissieux me donne le plein débit, comme visible sur les captures ci-dessous (le trou à 100% de perte de paquet est dû à un changement de profil sur l'OLT hier soir, je suis passé en Gigabit symétrique apparemment, et le changement de latence sur le graph pfsense est dû à un changement d'IP surveillée).
Si @Floyder ou une autre personne sait ce qu'il se passe, je suis preneur.
-
A vérifier ce soir, mais d'après ce que je vois le problème a été résolu aujourd'hui.
-
A vérifier ce soir, mais d'après ce que je vois le problème a été résolu aujourd'hui.
Merci bcp pour ton retour, si le problème est connu et en cours de traitement c'est une très bonne nouvelle.
Je vérifierai ce soir pour la latence et les pertes de paquets. Par contre pour l'instant le débit sur le noeud d'Aubagne est toujours divisé par 2 par rapport à la semaine dernière.
-
yep, je confirme, latence et perte de paquets dans la norme, pas de souci ce soir, jvais enfin pouvoir regarder The Mandalorian xD
(le noeud nperf d'Aubagne est toujours dans les choux, mais le reste est nickel)
Merci pour ton retour de cet après-midi :D
-
A priori les soucis de débit en download continuent, quelle que soit l'heure de la journée, même si côté latence et pertes de paquets c'est bel et bien résolu.
Tout ce qui n'est pas en BBR au niveau speedtest ne dépasse pas 100/120Mbits, le CDN de nvidia ne m'envoie pas plus de 120Mbits par session TCP au lieu du full gigabit habituel, idem pour cloudflare et OVH
@Floyder , est-ce que tu sais si un incident est en cours de ce côté là?
-
Rassurez-vous, c'est le cas dans toute la France ;D Tous les soirs leurs routeurs sont saturés. Ils vendent des fibres 1G, mais en réalité, ils n'ont pas la capacité réseau nécessaire pour assumer l'ensemble de leurs clients.
Exemple de MTR on voit bien la perte de paquet :
(https://cdn.discordapp.com/attachments/758046672650633317/1097610441460564092/image.png)
Il y a un mois j'avais ce problème entre 12h et 1h ils ont réussi à atténuer le problème maintenant ça recommence le soir.
-
Votre MTR ne montre pas de perte de paquets sur la cible 1.1.1.1 et c'est bien ce qui compte.
La latence finale est bonne aussi.
-
Bonsoir,
Il y a un mois j'avais ce problème entre 12h et 1h
Sur mon abo Red 1G/1G (theorique) j'ai eu exactement ces mêmes symptômes pendant plusieurs mois : coupure de l'accès internet de durée variable chaque jour entre 12h00 & 12h30, alors que tout était ok au niveau du routeur, de l'ONT, etc. Anomalie non signalée au service client car pas super gênante à part le week-end, et j'imaginais que c'était transitoire, vu les fibrages intensifs dans mon coin (sud-ouest).
Sauf que depuis bien 3 semaines, les coupures aléatoires se produisent dorénavant plusieurs fois par heure, ce qui rend quasi impossible le visionnage en streaming ou l'écoute de web radio sans que les flux soient régulièrement interrompus. Pour moi qui écoute beaucoup de musique en ligne, c'est très frustrant d'être réveillé par l'alarme par défaut faute de connexion à l'heure H, ou, quand ça marche, qu'un morceau s'interrompe plusieurs secondes en cours d'audition.
L'ONT n'indique aucune coupure de la liaison physique : ce sont vraiment les flux qui s'effondrent et les pings qui montent en flèche jusqu'au time-out.
Les débits max ont également bien baissé par rapport à l'installation de la fibre il y a 3 ans, où ça tapait le 1G symétrique (option Débit+ offerte lors du passage à l'offre fibre après l'ADSL). Depuis, c'est devenu très aléatoire, et plutôt du 450/200Mbps en soirée. Suffisant quand on se souvient du 56k ou de l'ADSL 512/128k, mais encore faut-il que les flux soient fiables. Je précise que la box est en IP v4 et a priori pas en CGNAT puisque le mode DMZ est accessible.
Avant de m'infliger un contact avec le service client pour un abo dont j'étais jusque là super content (5 ans chez RED après autant chez Free, et +10 ans auparavant chez Orange), j'ai évacué toutes les possibilités sur mon installation, et supprimé toutes les customisations. Je n'utilise pas le téléphone ni l'option TV.
Remise en service de la NB6V alors que l'ONT était en direct sur un routeur Synology (maintenant en DMZ), remise des DNS par défaut au lieu de NextDNS, changement de l'ONT, et même changement de box vers une NB6VAC de seconde main.
Que ce soit avec le précédent ou le plus récent, le diag ONT est stable.
J'ai même gagné 2dBm en installant le nouvel ONT, pourtant de modèle et firmware identiques :
Modèle I-010G-Q
Version principale 3FE7SWS4040018
Intensité signal optique reçue (dBm) -20.88 dBm
Intensité signal optique transmise (dBm) 4.46 dBm
Afin d'évacuer une problématique WiFi qu'on pourrait me reprocher, j'ai mis un docker Uptime Kuma sur le NAS, qui est le seul périphérique en réseau filaire sur le routeur. C'est pas joli joli :
(https://i.ibb.co/5nv75NR/Ping-Bing-1w.png) (https://i.ibb.co/5nv75NR/Ping-Bing-1w.png)
1 semaine de ping de bing.com toutes les 60 secondes
Vu les témoignages de ce fil, je comprends qu'il s'agit d'un pb national, et que rien ne sert de chercher encore un dysfonctionnement sur mon installation, qui donnait entière satisfaction jusque là.
J'ai un peu peur qu'on me balade sur la hotline, mais je ne vois pas comment se contenter d'un service aussi dégradé.
-
En général, un problème national est très vite identifié et corrigé. C'est souvent un problème de collecte local. Tu peux compléter ton num client dans ton profil ou poster un trace route vers 8.8.8.8 ?
-
En région, SFR utilise parfois la collecte des RIP XPfibre (ou autres?) et parfois, c'est pas beau (dans le 34 ou le 91 par exemple).
-
C'est souvent un problème de collecte local. Tu peux compléter ton num client dans ton profil ou poster un trace route vers 8.8.8.8 ?
Pardon pour cet abus de langage alors.
Mon profil a été mis à jour et voici le traceroute vers le DNS de google :
1 1 ms 1 ms 1 ms 192.168.1.1 (RT6600AX)
2 3 ms 2 ms 1 ms 192.168.5.1 (NB6VAC)
3 11 ms 8 ms 7 ms 10.153.16.219
4 11 ms 12 ms 8 ms 14.254.69.86.rev.sfr.net [86.69.254.14]
5 17 ms 15 ms 16 ms 71.146.6.194.rev.sfr.net [194.6.146.71]
6 14 ms 25 ms 17 ms 71.146.6.194.rev.sfr.net [194.6.146.71]
7 18 ms 18 ms 17 ms 72.14.194.30
8 18 ms 23 ms 21 ms 108.170.231.107
9 18 ms 17 ms 18 ms 142.251.253.35
10 15 ms 14 ms 18 ms dns.google [8.8.8.8]
Merci pour votre aide, si j'arrive à poster ce message malgré les coupures en cours. :P
Edith : mon PM de rattachement d'après l'ARCEP est le SRO-BPI-6524031
-
Allez, hop, après avoir préparé des copies d'écran du diagnostic de la box/ONT, du Speedtest (150Mbps sur un abo 1000/700), je me lance pour signaler les dysfonctionnements (qui perdurent), via l'appli « RED & Moi ».
Ce mercredi matin vers 10h00 et ce midi :
(https://i.ibb.co/7XHr15p/RED-SFR-sav-202030426.jpg) (https://i.ibb.co/7XHr15p/RED-SFR-sav-202030426.jpg)
Prochaine étape : les clients virtuels parleront aux assistant virtuels ? ::)
-
Hasard ou coïncidence, depuis que - faute de pouvoir joindre le SAV dans de bonnes conditions par l'appli et par téléphone - j'ai demandé mon RIO pour changer d'opérateur, le problème a été en partie réglé.
Il y a encore quelques anomalies de ping, mais la connexion ne coupe plus et le débit est correct.
Lorsque la dame très pro du service commercial (sans le brouhaha habituel derrière) n'a pas manqué d'appeler car "les clients qui demandent leur RIO ont en général des problèmes de ligne téléphonique", elle a proposé de me mettre en relation avec un technicien.
Je lui ai signalé que ma décision était irrévocable et qu'il n'était pas nécessaire d'insister.
Le même numéro de téléphone a ensuite quand même tenté de me rappeler près de 20 fois en deux jours. ;D