La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => SFR / RED => 
Débit fibre SFR => Discussion démarrée par: xuaeser le 16 février 2023 à 16:44:03
-
Salut,
Depuis la nuit du 9/12/2022 suite à une coupure de ma ligne fibre pendant plusieurs heures (probablement une maintenance planifiée, migration PE Ericsson|Redback vers Nokia ?), je constate des soucis de débit sur toutes les sessions TCP CUBIC.
Le soucis est présent 24h/24h et 7j/7. Il ne s'agit pas de saturation temporaire aux heures de pointe.
Depuis des serveurs parisiens, je mesure environ 45Mbps en download, et 470Mbps en upload. (test iperf3 depuis/vers ping.online.net)
Je suspect très fortement un soucis de configuration sur les PE SFR concernant le policing/shaping appliqué.
Après analyse d'une capture d'un flux TCP, je pense à un soucis de buffer trop petit (cbs), ce qui engendre de la perte de paquet et empêche TCP de monter en débit.
Je pense que le buffer configuré est de l'ordre d'1ms (120ko), au lieu des 10-15ms nécessaires.
Je constate strictement le même soucis sur la ligne SFR d'un collègue (également en région Lyonnaise, mais dans un quartier différent).
Connexion SFR, Téléchargement depuis un serveur utilisant TCP Cubic (ping.online.net): 40Mbps
Connexion SFR, Téléchargement depuis un serveur utilisant TCP BBR (ipv4.scaleway.testdebit.info): 456Mbps
rtr-sfr:~$ wget -O /dev/null http://ping.online.net/1000Mo.dat
--2023-02-13 14:53:43-- http://ping.online.net/1000Mo.dat
Résolution de ping.online.net (ping.online.net)… 62.210.18.40
Connexion à ping.online.net (ping.online.net)|62.210.18.40|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1000000000 (954M) [application/octet-stream]
Sauvegarde en : « /dev/null »
2023-02-13 14:56:53 (5,00 MB/s) — « /dev/null » sauvegardé [1000000000/1000000000]
rtr-sfr:~$ wget -O /dev/null http://ipv4.scaleway.testdebit.info/1G.iso
--2023-02-13 14:58:03-- http://ipv4.scaleway.testdebit.info/1G.iso
Résolution de ipv4.scaleway.testdebit.info (ipv4.scaleway.testdebit.info)… 62.210.156.7
Connexion à ipv4.scaleway.testdebit.info (ipv4.scaleway.testdebit.info)|62.210.156.7|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1000000000 (954M) [application/x-iso9660-image]
Sauvegarde en : « /dev/null »
2023-02-13 14:58:19 (57,0 MB/s) — « /dev/null » sauvegardé [1000000000/1000000000]
La hotline SFR ne sait pas sortir de ses scripts. Le service "expertise" dit que s'il n'y a pas 5 personnes avec le même problème, ils ne peuvent pas faire remonter un soucis généralisé. Et de toute manière comme https://www.sfr.fr/mire-test-debit/ remonte des résultats décent, il n'y a pas de problème.
Y a t-il par ici des abonnés SFR/RED qui constatent le même soucis ? :)
Ou encore mieux, des gens qui aurait moyen de remonter le soucis aux bonnes personnes ?
-
Renseigne ta ref client dans ton profile stp ;)
-
Voila qui est fait, j'ai renseigné ma ref client ! :)
-
Salut,
Le problème est toujours bien présent.
Ce n'est pas un soucis côté box (elle a été remplacée par la hotline, et de toute manière en temps normal je ne l'utilise pas, j'ai un routeur perso directement sur l'ONT).
Je suis quasiment sûr que le soucis ne viens pas de mon LAN/équipements. J'ai fait des tonnes de tests, et le collègue lyonnais reproduit exactement le même soucis.
Je ne cherche pas à faire fumer les records sur les speedtest, mais la, 40Mbps en down c'est un peu juste et ça se ressent bien sur les gros téléchargement !
-
Tu as testé avec le programme de notre ami Ouno ?
https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/
enlève peut être le test Freebox (-F)
-
Je ne connaissais pas ce petit script !
Il reproduit les tests que j'ai fait à la main avec du wget/iperf, et même résultats:
[checkFtthFree v0.12] Linux 5.10.0-19-amd64 (x86_64)
-------------------------- 2023-03-14 11:36:24 +0100 --------------------------
Paramétrage réseau actuel du système:
net.core.default_qdisc: fq_codel
net.core.rmem_max: 212992
net.core.wmem_max: 212992
net.ipv4.tcp_adv_win_scale: 1
net.ipv4.tcp_congestion_control: cubic
net.ipv4.tcp_mem: 5235 6981 10470
net.ipv4.tcp_no_metrics_save: 0
net.ipv4.tcp_rmem: 4096 131072 3574752
net.ipv4.tcp_sack: 1
net.ipv4.tcp_timestamps: 1
net.ipv4.tcp_window_scaling: 1
net.ipv4.tcp_wmem: 4096 16384 3574752
=> Latence TCP max pour une réception à 1 Gbps: 15 ms
=> Latence TCP max pour une émission à 700 Mbps: 30 ms
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 10.42 ms [gigue: 0.18 ms]
--> Débit: 64.74 Mo/s (517.90 Mbps) [fluctuation: 1.03%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 9.98 ms [gigue: 0.21 ms]
--> Débit: 5.71 Mo/s (45.66 Mbps) [fluctuation: 15.96%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 8.82%)
-------------------------- 2023-03-14 11:36:49 +0100 --------------------------
45Mbps en TCP Cubic depuis Scaleway.
Contre 520Mpbs avec BBR.
-
Tu n'a pas le même default_qdisc que moi, et moins de tcp_mem (j'ai Debian 10 si je dis pas de connerie, rien installé dessus, juste une VM)
je ne sais pas si ça peut influencer, et le BBR fonctionne correctement (enfin si tu as une connexion 500Mb/s, sinon ce n'est pas bon non plus)
je ne sais pas si @ouno peut nous éclairer :D
[checkFtthFree v0.11] Linux 5.10.0-21-amd64 (x86_64)
-------------------------- 2023-03-10 08:57:51 +0100 --------------------------
Paramétrage réseau actuel du système:
net.core.default_qdisc: pfifo_fast
net.core.rmem_max: 212992
net.core.wmem_max: 212992
net.ipv4.tcp_adv_win_scale: 1
net.ipv4.tcp_congestion_control: cubic
net.ipv4.tcp_mem: 10077 13437 20154
net.ipv4.tcp_no_metrics_save: 0
net.ipv4.tcp_rmem: 4096 131072 6291456
net.ipv4.tcp_sack: 1
net.ipv4.tcp_timestamps: 1
net.ipv4.tcp_window_scaling: 1
net.ipv4.tcp_wmem: 4096 16384 4194304
=> Latence TCP max pour une réception à 1 Gbps: 27 ms
=> Latence TCP max pour une émission à 700 Mbps: 35 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.77 ms [gigue: 0.05 ms]
--> Débit: 116.01 Mo/s (928.11 Mbps) [fluctuation: 2.21%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.14 ms [gigue: 0.44 ms]
--> Débit: 106.40 Mo/s (851.22 Mbps) [fluctuation: 5.11%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 9.06 ms [gigue: 0.65 ms]
--> Débit: 109.67 Mo/s (877.33 Mbps) [fluctuation: 0.44%]
-------------------------- 2023-03-10 08:58:29 +0100 --------------------------
-
Pour la science, je me suis mis en pfifo_fast, avec les mêmes valeurs sur tcp_mem. Ça ne change rien.
-------------------------- 2023-03-14 18:11:07 +0100 --------------------------
Paramétrage réseau actuel du système:
net.core.default_qdisc: pfifo_fast
net.core.rmem_max: 212992
net.core.wmem_max: 212992
net.ipv4.tcp_adv_win_scale: 1
net.ipv4.tcp_congestion_control: cubic
net.ipv4.tcp_mem: 10077 13437 20154
net.ipv4.tcp_no_metrics_save: 0
net.ipv4.tcp_rmem: 4096 131072 3574752
net.ipv4.tcp_sack: 1
net.ipv4.tcp_timestamps: 1
net.ipv4.tcp_window_scaling: 1
net.ipv4.tcp_wmem: 4096 16384 3574752
=> Latence TCP max pour une réception à 1 Gbps: 15 ms
=> Latence TCP max pour une émission à 700 Mbps: 30 ms
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 10.46 ms [gigue: 0.32 ms]
--> Débit: 65.87 Mo/s (527.00 Mbps) [fluctuation: 2.59%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 10.03 ms [gigue: 0.15 ms]
--> Débit: 5.81 Mo/s (46.50 Mbps) [fluctuation: 7.15%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 8.82%)
-------------------------- 2023-03-14 18:11:32 +0100 --------------------------
Edit: avec un PC sous windows au cul de la box: tout pareil:
-------------------------- 2023-03-14 18:41:12 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Public
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 10.58 ms [gigue: 1.41 ms]
--> Débit: 66.67 Mo/s (533.32 Mbps) [fluctuation: 5.71%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 10.28 ms [gigue: 1.28 ms]
--> Débit: 4.86 Mo/s (38.91 Mbps) [fluctuation: 19.62%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 7.29%)
-------------------------- 2023-03-14 18:41:43 +0100 --------------------------
-
Ok donc vraisemblablement un soucis au niveau de SFR ou du réseau :-\
-
je ne sais pas si @ouno peut nous éclairer :D
A priori pas de souci de conf de taille de buffer tcp, sinon le script l'aurait indiqué.
Ce qu'il est possible de faire éventuellement c'est lancer le script avec le paramètre -a pour essayer avec des serveurs de test alternatifs, mais ce sera sûrement pareil...
-
En effet, résultats similaires depuis les serveurs hébergés dans le réseau de Bouygues:
-------------------------- 2023-03-15 13:40:51 +0100 --------------------------
Paramétrage réseau actuel du système:
net.core.default_qdisc: pfifo_fast
net.core.rmem_max: 212992
net.core.wmem_max: 212992
net.ipv4.tcp_adv_win_scale: 1
net.ipv4.tcp_congestion_control: cubic
net.ipv4.tcp_mem: 10077 13437 20154
net.ipv4.tcp_no_metrics_save: 0
net.ipv4.tcp_rmem: 4096 131072 3574752
net.ipv4.tcp_sack: 1
net.ipv4.tcp_timestamps: 1
net.ipv4.tcp_window_scaling: 1
net.ipv4.tcp_wmem: 4096 16384 3574752
=> Latence TCP max pour une réception à 1 Gbps: 15 ms
=> Latence TCP max pour une émission à 700 Mbps: 30 ms
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 9.91 ms [gigue: 0.11 ms]
--> Débit: 64.02 Mo/s (512.13 Mbps) [fluctuation: 1.92%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 9.97 ms [gigue: 0.24 ms]
--> Débit: 6.84 Mo/s (54.72 Mbps) [fluctuation: 4.67%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 10.68%)
-------------------------- 2023-03-15 13:41:16 +0100 --------------------------
-
C'est pareil en IPv6 j'imagine ? (paramètre -6)
-
Oui, je ne l'avais pas précisé ici mais c'est pareil en IPv6.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.81 ms [gigue: 0.06 ms]
--> Débit: 64.49 Mo/s (515.94 Mbps) [fluctuation: 1.85%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 9.64 ms [gigue: 0.14 ms]
--> Débit: 5.04 Mo/s (40.30 Mbps) [fluctuation: 1.50%]
-
J'ai poursuivi un peu les investigations, avec des mesures iperf3, en UDP, depuis un serveur Lyonnais situé à moins de 3ms de chez moi (mais en dehors du réseau SFR quand même).
iperf3, UDP, mesure du sens descendant de la FTTH, pacing-timer par defaut (1ms):
| Débit émis | Débit reçu | % perte paquet |
| 5.00 Mbps | 4.99 Mbps | < 0.2% |
| 25.0 Mbps | 25.0 Mbps | < 0.2% |
| 50.0 Mbps | 50.0 Mbps | < 0.2% |
| 100 Mbps | 99.9 Mbps | < 0.2% |
| 200 Mbps | 200 Mbps | < 0.2% |
| 300 Mbps | 299 Mbps | < 0.2% |
| 400 Mbps | 399 Mbps | < 0.2% |
| 500 Mbps | 498 Mbps | 0.3% |
| 550 Mbps | 548 Mbps | 0.22% |
| 600 Mbps | 573 Mbps | 4.3% |
| 650 Mbps | 571 Mbps | 12% |
| 700 Mbps | 573 Mbps | 18% |
| 800 Mbps | 550 Mbps | 31% |
| 900 Mbps | 536 Mbps | 40% |
On vois qu'il y a systématiquement de la perte de paquet. Même sur des faibles débits, impossible d'être à 0% de perte.
On plafonne vers 550-570Mbps.
Maintenant, refaisons les tests, en ne changeant qu'un seul paramètre: --pacing-timer 10
iperf3, UDP, mesure du sens descendant de la FTTH, --pacing-timer 10 (10μs):
| Débit émis | Débit reçu | % perte paquet |
| 5.00 Mbps | 4.99 Mbps | 0.25% |
| 25.0 Mbps | 24.9 Mbps | 0.25% |
| 50.0 Mbps | 50.0 Mbps | < 0.2% |
| 100 Mbps | 99.9 Mbps | < 0.2% |
| 200 Mbps | 200 Mbps | < 0.2% |
| 300 Mbps | 299 Mbps | < 0.2% |
| 400 Mbps | 399 Mbps | < 0.2% |
| 500 Mbps | 499 Mbps | < 0.2% |
| 600 Mbps | 599 Mbps | < 0.2% |
| 700 Mbps | 698 Mbps | < 0.2% |
| 800 Mbps | 796 Mbps | 0.35% |
| 900 Mbps | 895 Mbps | 0.41% |
Il y a toujours de la perte par tout a fait négligeable, mais on arrive quasiment au 1 Gbps de l'offre commerciale.
Ce sont bien les pertes de paquet qui empêchent TCP de monter en débit, en particulier quand TCP Cubic est utilisé.
Après, où disparaissent ces paquets...
Les résultats bruts:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-600.00 sec 358 MBytes 5.00 Mbits/sec 0.000 ms 0/258978 (0%) sender
[ 5] 0.00-600.05 sec 357 MBytes 4.99 Mbits/sec 0.103 ms 242/258978 (0.093%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-240.00 sec 715 MBytes 25.0 Mbits/sec 0.000 ms 0/517954 (0%) sender
[ 5] 0.00-240.04 sec 714 MBytes 25.0 Mbits/sec 0.051 ms 641/517954 (0.12%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-120.00 sec 715 MBytes 50.0 Mbits/sec 0.000 ms 0/517952 (0%) sender
[ 5] 0.00-120.04 sec 715 MBytes 50.0 Mbits/sec 0.019 ms 18/517952 (0.0035%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-60.00 sec 715 MBytes 100 Mbits/sec 0.000 ms 0/517949 (0%) sender
[ 5] 0.00-60.04 sec 715 MBytes 99.9 Mbits/sec 0.016 ms 12/517949 (0.0023%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 715 MBytes 200 Mbits/sec 0.000 ms 0/517942 (0%) sender
[ 5] 0.00-30.04 sec 715 MBytes 200 Mbits/sec 0.015 ms 141/517942 (0.027%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 1.05 GBytes 300 Mbits/sec 0.000 ms 0/776914 (0%) sender
[ 5] 0.00-30.04 sec 1.05 GBytes 299 Mbits/sec 0.014 ms 328/776914 (0.042%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.000 ms 0/1035886 (0%) sender
[ 5] 0.00-30.04 sec 1.40 GBytes 399 Mbits/sec 0.013 ms 416/1035886 (0.04%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 1.75 GBytes 500 Mbits/sec 0.000 ms 0/1294859 (0%) sender
[ 5] 0.00-30.04 sec 1.74 GBytes 498 Mbits/sec 0.011 ms 3864/1294859 (0.3%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 1.92 GBytes 550 Mbits/sec 0.000 ms 0/1424345 (0%) sender
[ 5] 0.00-30.04 sec 1.92 GBytes 548 Mbits/sec 0.013 ms 3111/1424345 (0.22%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 2.10 GBytes 600 Mbits/sec 0.000 ms 0/1553834 (0%) sender
[ 5] 0.00-30.04 sec 2.01 GBytes 573 Mbits/sec 0.012 ms 66974/1553828 (4.3%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 2.27 GBytes 650 Mbits/sec 0.000 ms 0/1683320 (0%) sender
[ 5] 0.00-30.04 sec 2.00 GBytes 571 Mbits/sec 0.013 ms 203634/1683314 (12%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 2.44 GBytes 700 Mbits/sec 0.000 ms 0/1812809 (0%) sender
[ 5] 0.00-30.04 sec 2.00 GBytes 573 Mbits/sec 0.011 ms 327106/1812796 (18%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 2.79 GBytes 800 Mbits/sec 0.000 ms 0/2071782 (0%) sender
[ 5] 0.00-30.04 sec 1.92 GBytes 550 Mbits/sec 0.013 ms 646605/2071757 (31%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 3.14 GBytes 900 Mbits/sec 0.000 ms 0/2330759 (0%) sender
[ 5] 0.00-30.04 sec 1.88 GBytes 536 Mbits/sec 0.012 ms 940111/2330728 (40%) receiver
PACING --pacing-timer 10
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-600.00 sec 358 MBytes 5.00 Mbits/sec 0.000 ms 0/258978 (0%) sender
[ 5] 0.00-600.04 sec 357 MBytes 4.99 Mbits/sec 0.070 ms 652/258978 (0.25%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-240.00 sec 715 MBytes 25.0 Mbits/sec 0.000 ms 0/517956 (0%) sender
[ 5] 0.00-240.04 sec 713 MBytes 24.9 Mbits/sec 0.032 ms 1279/517956 (0.25%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-120.00 sec 715 MBytes 50.0 Mbits/sec 0.000 ms 0/517956 (0%) sender
[ 5] 0.00-120.04 sec 715 MBytes 50.0 Mbits/sec 0.018 ms 232/517956 (0.045%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-60.00 sec 715 MBytes 100 Mbits/sec 0.000 ms 0/517956 (0%) sender
[ 5] 0.00-60.04 sec 715 MBytes 99.9 Mbits/sec 0.008 ms 214/517956 (0.041%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-60.00 sec 1.40 GBytes 200 Mbits/sec 0.000 ms 0/1035911 (0%) sender
[ 5] 0.00-60.04 sec 1.40 GBytes 200 Mbits/sec 0.027 ms 310/1035911 (0.03%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 1.05 GBytes 300 Mbits/sec 0.000 ms 0/776934 (0%) sender
[ 5] 0.00-30.04 sec 1.05 GBytes 299 Mbits/sec 0.019 ms 346/776932 (0.045%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.000 ms 0/1035911 (0%) sender
[ 5] 0.00-30.04 sec 1.40 GBytes 399 Mbits/sec 0.018 ms 167/1035908 (0.016%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 1.75 GBytes 500 Mbits/sec 0.000 ms 0/1294890 (0%) sender
[ 5] 0.00-30.04 sec 1.75 GBytes 499 Mbits/sec 0.017 ms 600/1294886 (0.046%) receiver
[ 5] 0.00-30.00 sec 2.10 GBytes 600 Mbits/sec 0.000 ms 0/1553868 (0%) sender
[ 5] 0.00-30.05 sec 2.09 GBytes 599 Mbits/sec 0.034 ms 1181/1553868 (0.076%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 2.44 GBytes 700 Mbits/sec 0.000 ms 0/1812845 (0%) sender
[ 5] 0.00-30.04 sec 2.44 GBytes 698 Mbits/sec 0.018 ms 1537/1812842 (0.085%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 2.79 GBytes 800 Mbits/sec 0.000 ms 0/2071820 (0%) sender
[ 5] 0.00-30.05 sec 2.78 GBytes 796 Mbits/sec 0.016 ms 7322/2071820 (0.35%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 3.14 GBytes 900 Mbits/sec 0.000 ms 0/2330799 (0%) sender
[ 5] 0.00-30.05 sec 3.13 GBytes 895 Mbits/sec 0.015 ms 9472/2330799 (0.41%) receiver
-
ce sont des iperf sous windows ou linux ? car sous windows j'ai de grosses pertes que je n'ai pas sous linux par exemple, le client iperf sous windows est un peu foireux je trouve.
-
iperf3 3.9 sous Debian Bullseye côté serveur et client.
Et pareil, iperf3 sous windows, ça fait parfois des truc louche...
-
Tu es dans une zone en cours d'upgrade. Ce que tu observes semble lié à des écarts de génération importants entre les différents équipements. Ça devrait rentrer dans l'ordre lorsque la zone sera finalisée.
-
Merci Floyder pour ce retour ! Vu de loin ça semble un peu étrange, mais si l'équipe qui gère ça s'est penchée dessus c'est déjà cool.
Le 28/04 j'ai résilié dans mon espace client l'option "Débit Plus" (1G down 700 up), pour voir si ce n'était pas le profil lié à cette option qui était problématique.
Aujourd’hui je mesure des débits encore plus catastrophiques que d'habitude. Peut être une saturation temporaire, mais bon 10Mbps... Bientôt presque moins bon qu'en ADSL !
$ iperf3 -c ping.online.net -p 5207 -R
Connecting to host ping.online.net, port 5207
Reverse mode, remote host ping.online.net is sending
[ 5] local 192.168.1.42 port 49150 connected to 62.210.18.40 port 5207
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 1.36 MBytes 11.4 Mbits/sec
[ 5] 1.00-2.00 sec 1.20 MBytes 10.0 Mbits/sec
[ 5] 2.00-3.00 sec 1.10 MBytes 9.24 Mbits/sec
[ 5] 3.00-4.00 sec 1.22 MBytes 10.2 Mbits/sec
[ 5] 4.00-5.00 sec 1.35 MBytes 11.3 Mbits/sec
[ 5] 5.00-6.00 sec 1.72 MBytes 14.4 Mbits/sec
[ 5] 6.00-7.00 sec 1.40 MBytes 11.7 Mbits/sec
[ 5] 7.00-8.00 sec 1.34 MBytes 11.2 Mbits/sec
[ 5] 8.00-9.00 sec 953 KBytes 7.81 Mbits/sec
[ 5] 9.00-10.00 sec 1.56 MBytes 13.1 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 13.3 MBytes 11.1 Mbits/sec 494 sender
[ 5] 0.00-10.00 sec 13.2 MBytes 11.0 Mbits/sec receiver
iperf Done.
$ date
lun. 01 mai 2023 12:02:15 CEST
@Floyder si jamais tu as une idée du planning je suis preneur (environ combien de temps il faut pour que la zone soit upgradée complètement). Ça fait 5mois que le pb est présent (9/12)
Edit: Je suis retourné autour des environ 50Mbps habituel en down.
-
Le problème est toujours bien présent. Aucune évolution en mieux ou moins bien.
Après plus de 6 mois a patienter je me dit que ça serait sûrement plus efficace de partir à la concurrence que d'espérer que SFR répare son réseau. :-\
-
Visiblement le problème est toujours présent en région lyonnaise.
[checkFtthFree v0.14] Linux 6.2.0-39-generic (x86_64)
-------------------------- 2023-12-15 14:35:51 +0100 --------------------------
Paramétrage réseau actuel du système:
net.core.default_qdisc: fq
net.core.rmem_max: 33554432
net.core.wmem_max: 33554432
net.ipv4.tcp_adv_win_scale: 1
net.ipv4.tcp_congestion_control: bbr
net.ipv4.tcp_mem: 186483 248646 372966
net.ipv4.tcp_no_metrics_save: 1
net.ipv4.tcp_rmem: 4096 131072 33554432
net.ipv4.tcp_sack: 1
net.ipv4.tcp_timestamps: 1
net.ipv4.tcp_window_scaling: 1
net.ipv4.tcp_wmem: 4096 87380 33554432
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
=> Latence TCP max pour une émission à 700 Mbps: 283 ms
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 12.76 ms [gigue: 0.15 ms]
--> Débit: 60.12 Mo/s (480.96 Mbps) [fluctuation: 10.92%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 12.40 ms [gigue: 0.75 ms]
--> Débit: 6.06 Mo/s (48.48 Mbps) [fluctuation: 6.01%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 10.08%)
-
Oui, toujours aucune amélioration. ça fait plus d'un an que le problème est présent chez moi.
Perso je n'utilise plus cette ligne FTTH SFR, je l'ai gardé en secours pour l'instant.
-
Je ne sais pas si Floyder qui avait des infos sur un upgrade de la zone pourrait nous en dire plus sur l'avancement du chantier mais c'est clair que c'est frustrant de voir la situation s'éterniser...
-
Je suis passé voir un pote sur Lyon 7 hier et lui ne semblait pas impacté.
C’est bien frustrant et je ne vois pas comment faire remonter l’info via l’assistance (si je leur parle de bbr et cubic je vais sûrement les perdre)…
-
Je suis dans une zone limité au 1G (selon l'éligibilité du site SFR) tandis qu'à l'adresse de mon ami le 2G est proposé.
Les problèmes en Cubic seraient-ils liés aux zones avec un matériel plus ancien également limité en débit ?
-
C'est effectivement lié à la première génération d'OLT, qui a du mal à encaisser ce que peut fournir le nouveau réseau de collecte en burst. Le remplacement de ces OLT est un programme en cours depuis plusieurs années.
-
Toute la question est donc combien de temps avant un remplacement et un retour à la normale... :-\
-
Bien sûr tout ce que le SAV sait faire c'est de réinitialiser la box (ce qui m'a fait perdre ipv6 en passant, il a fallu que je le réactive) et de dire que vu que le débit vers mire.sfr.fr est bon alors ils ne peuvent rien faire...
-
C'est effectivement lié à la première génération d'OLT, qui a du mal à encaisser ce que peut fournir le nouveau réseau de collecte en burst. Le remplacement de ces OLT est un programme en cours depuis plusieurs années.
La tristesse, un upgrade du réseau de collecte qui se traduit par une dégradation drastique des perfs pour les abonnés !
C'est quand même surprenant que ça perde autant et que TCP n'arrive pas à monter en débit.
Il n'y aurait pas moyen de limiter les burst en amont sur les PE ?
-
La tristesse, un upgrade du réseau de collecte qui se traduit par une dégradation drastique des perfs pour les abonnés !
C'est quand même surprenant que ça perde autant et que TCP n'arrive pas à monter en débit.
Il n'y aurait pas moyen de limiter les burst en amont sur les PE ?
Après il faut voir l'impact réel en utilisation classique d'internet. Les tests de débits sont mauvais car ils sont par nature fait pour tester les limites, et effectivement en limite dans cette configuration d'infra il y a beaucoup de drop.
Mais entre ça et un réseau de collecte qui sature de 18h à 23h, je pense qu'il n'y a pas photo.
-
Après il faut voir l'impact réel en utilisation classique d'internet. Les tests de débits sont mauvais car ils sont par nature fait pour tester les limites, et effectivement en limite dans cette configuration d'infra il y a beaucoup de drop.
Mais entre ça et un réseau de collecte qui sature de 18h à 23h, je pense qu'il n'y a pas photo.
Concrètement au quotidien c'est quand même vachement impactant : mes téléchargements de mise à jour d'applis sur mon iPhone sont facile 5 fois plus lent qu'avec un VPN ou via la connexion Orange de mes parents...
C'est clairement perceptible à l'usage, pas besoin de benchmark/speedtest/whatever pour sentir la lenteur liée.
Idem pour télécharger des fichiers sur le net, etc...
Donc oui j'ai toujours au moins 50-60Mb/s en Cubic 24h/24, 7j/7 mais au final je n'ai que 50-60Mb/s vers 75% de l'Internet 24h/24, 7j/7.
Quand on vend une connexion 1Gb/s c'est quand même faiblard...
Si au moins c'était 2-300Mb/s ça serait plus transparent et je me poserais pas la question face à du sosh à 300Mb/s.
Mais entre ça et le SAV qui te raccroche au nez quand tu leur dis qu'Internet ne se limite pas au speedtest sfr, ça donne quand même l'impression de prendre l'abonné pour un pigeon.
Si au moins on avait une date pour le changement d'équipement mais même pas...
Et autant 2-3 mois ça peut se justifier autant 1 an c'est incompréhensible...
-
Alors oui, entre choisir entre un réseau horrible qui marche quasi pas aux heure de pointe, et un 50Mbps stable, on prend le 50Mbps stable.
Mais avant cet upgrade du réseau de collecte, ça ne saturait pas du tout hein. Donc c'est bien une dégradation assez visible du service qui s'est produite, et qui dure.
Perso les speedtest, je m'en fiche. Par contre, les téléchargements de fichier/maj de l'OS/maj de jeux qui mettent 10 ou 20 fois plus de temps que ce qu'on attend sur une connexion FTTH fonctionnelle, au bout d'un moment ça agace.
Sur du surf web standard, on est d'accord ça ne se voit pas.