Le débit n'est pas ouf actuellement, 300mb, mais clairement suffisant.

J'ai récupéré mon accès fibre hier à partir de 12h, et rien à déplorer également dans le Nord t'es sur que ça ne provient pas de ta carte réseau ou autre ?

Il y a du partage de fibre sur quelques zones (limitées), mais les équipements actifs sont distincts.

Donc de ce que je comprends bien, il est possible que SFR (Numericable) en FTTLA n'est pas géré par la même équipe que SFR ADSL et FTTH ?

Le peering est-il toujours distincts, entre le FTTLA et le FTTH ?

Cependant, je regrette un peu d'être passé à la FTTH parfois mon ancien accès en Coaxial (1Gb/60Mb) avait moins de problèmes de stabilité.

Le seul point positif que je trouve, c'est que j'ai un accès IPv6 désormais et un upload bien plus élevé.

A+

Et c'est reparti pour le débit catastrophique...
Sauf que j'ai pu faire plus de tests.
Dans un premier temps, un Nperf, même sur un serveur Orange, ne donne rien:


Et mon serveur kimsufi se tourne les pouces alors que le visionnage ne fait que se couper toutes les 10 secondes...:


Par acquis de conscience, je lance en ligne de commande un speedtest à partir du serveur, RAS:
root@ns330670:/home/debian# speedtest

   Speedtest by Ookla

      Server: Nextmap - LeKloud - Paris (id: 33869)
         ISP: OVH SAS
Idle Latency:     5.39 ms   (jitter: 0.13ms, low: 5.27ms, high: 5.48ms)
    Download:    93.62 Mbps (data used: 42.3 MB)                                                   
                 17.75 ms   (jitter: 1.73ms, low: 7.94ms, high: 29.20ms)
      Upload:    91.04 Mbps (data used: 41.1 MB)                                                   
                 12.02 ms   (jitter: 1.04ms, low: 6.27ms, high: 15.35ms)
 Packet Loss:     0.0%
  Result URL: https://www.speedtest.net/result/c/004d4772-b619-4939-a3bd-443c7c2e3b30

Mais si je lance un DL, les débits sonts véritablement catastrophiques:


J'ai utilisé le script Perl checkffthfree trouvable sur le forum ici:

https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/

et j'obtiens ça:
kkwete@kkwete:~/Bureau$ perl checkFtthFree.pl
===============================================================================
checkFtthFree
---------------
Programme de diagnostic de connexion FTTH Free

Ce programme analyse la configuration réseau du système et effectue différents
tests TCP (latence et débit mono-connexion) afin d'évaluer les performances de
la connexion FTTH et détecter d'éventuels dysfonctionnements.
Diverses options sont disponibles pour configurer ou désactiver certains tests,
voir --help (-h) pour plus d'information.

Avant de continuer, veuillez vérifier que rien d'autre ne consomme de la bande
passante sur le réseau (ordinateurs, Freebox player, télévision...), ni du CPU
sur le système de test (mises à jour automatiques, antivirus...).
===============================================================================
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...


[checkFtthFree v0.12]                          Linux 5.4.0-156-generic (x86_64)
-------------------------- 2023-08-26 22:01:10 +0200 --------------------------
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: 189372 252496 378744
  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
[!] Echec du test de latence
    En cas d'absence de Freebox, le paramètre --skip-freebox (-F) peut être utilisé pour désactiver le test local

Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
  --> Latence: 43.92 ms [gigue: 3.05 ms]
[!] Latence élevée pour une connexion FTTH
[!] Avec cette latence, le paramétrage actuel de mémoire tampon TCP pourrait limiter le débit en réception à environ 71.62 Mo/s (572.99 Mbps)
  --> Débit: 38.29 Mo/s (306.32 Mbps) [fluctuation: 15.72%]

Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
  --> Latence: 43.38 ms [gigue: 2.57 ms]
[!] Latence élevée pour une connexion FTTH
[!] Avec cette latence, le paramétrage actuel de mémoire tampon TCP pourrait limiter le débit en réception à environ 72.52 Mo/s (580.13 Mbps)
  --> Débit: 388.42 Ko/s (3.11 Mbps) [fluctuation: 40.28%]

[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
      (ratio débit CUBIC/BBR: 1.01%)
-------------------------- 2023-08-26 22:01:40 +0200 --------------------------
kkwete@kkwete:~/Bureau$

On voit très clairement un débit dans les choux en TCP avec CUBIC.
Mon problème viendrait de là?
Si oui, que puis-je faire? (en dehors de changer de FAI, ce qui me démange fortement, je dois bien l'avouer...)
Je testerai le même script à une heure où tout fonctionne pour être sûr que mon pb vient bien de là.

Et allez, c'est reparti comme hier, toujours à partir de 19h environ...

Aucun souci:
kkwete@kkwete:~/Bureau$ perl checkFtthFree.pl -F
===============================================================================
checkFtthFree
---------------
Programme de diagnostic de connexion FTTH Free

Ce programme analyse la configuration réseau du système et effectue différents
tests TCP (latence et débit mono-connexion) afin d'évaluer les performances de
la connexion FTTH et détecter d'éventuels dysfonctionnements.
Diverses options sont disponibles pour configurer ou désactiver certains tests,
voir --help (-h) pour plus d'information.

Avant de continuer, veuillez vérifier que rien d'autre ne consomme de la bande
passante sur le réseau (ordinateurs, Freebox player, télévision...), ni du CPU
sur le système de test (mises à jour automatiques, antivirus...).
===============================================================================
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...


[checkFtthFree v0.12]                          Linux 5.4.0-156-generic (x86_64)
-------------------------- 2023-08-27 20:56:40 +0200 --------------------------
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: 189372 252496 378744
  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 Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
  --> Latence: 45.62 ms [gigue: 1.48 ms]
[!] Latence élevée pour une connexion FTTH
[!] Avec cette latence, le paramétrage actuel de mémoire tampon TCP pourrait limiter le débit en réception à environ 68.96 Mo/s (551.64 Mbps)
  --> Débit: 28.30 Mo/s (226.41 Mbps) [fluctuation: 9.49%]

Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
  --> Latence: 44.98 ms [gigue: 1.85 ms]
[!] Latence élevée pour une connexion FTTH
[!] Avec cette latence, le paramétrage actuel de mémoire tampon TCP pourrait limiter le débit en réception à environ 69.94 Mo/s (559.49 Mbps)
  --> Débit: 282.30 Ko/s (2.26 Mbps) [fluctuation: 20.28%]

[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
      (ratio débit CUBIC/BBR: 1.00%)
-------------------------- 2023-08-27 20:57:06 +0200 --------------------------
kkwete@kkwete:~/Bureau$ perl checkFtthFree.pl -F -a
===============================================================================
checkFtthFree
---------------
Programme de diagnostic de connexion FTTH Free

Ce programme analyse la configuration réseau du système et effectue différents
tests TCP (latence et débit mono-connexion) afin d'évaluer les performances de
la connexion FTTH et détecter d'éventuels dysfonctionnements.
Diverses options sont disponibles pour configurer ou désactiver certains tests,
voir --help (-h) pour plus d'information.

Avant de continuer, veuillez vérifier que rien d'autre ne consomme de la bande
passante sur le réseau (ordinateurs, Freebox player, télévision...), ni du CPU
sur le système de test (mises à jour automatiques, antivirus...).
===============================================================================
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...


[checkFtthFree v0.12]                          Linux 5.4.0-156-generic (x86_64)
-------------------------- 2023-08-27 20:57:16 +0200 --------------------------
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: 189372 252496 378744
  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 Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
  --> Latence: 43.86 ms [gigue: 2.40 ms]
[!] Latence élevée pour une connexion FTTH
[!] Avec cette latence, le paramétrage actuel de mémoire tampon TCP pourrait limiter le débit en réception à environ 71.72 Mo/s (573.78 Mbps)
  --> Débit: 13.27 Mo/s (106.19 Mbps) [fluctuation: 43.95%]

Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
  --> Latence: 46.75 ms [gigue: 12.64 ms]
[!] Latence élevée pour une connexion FTTH
[!] Avec cette latence, le paramétrage actuel de mémoire tampon TCP pourrait limiter le débit en réception à environ 67.29 Mo/s (538.31 Mbps)
  --> Débit: 282.22 Ko/s (2.26 Mbps) [fluctuation: 52.66%]

[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
      (ratio débit CUBIC/BBR: 2.13%)
-------------------------- 2023-08-27 20:57:44 +0200 --------------------------
kkwete@kkwete:~/Bureau$

Bref, c'est bien pourri...Impossible de me servir de mon serveur Plex avec ces débits. Finalement, en semaine, je ne peux m'ens ervir que quand je travaille...

Bonsoir, a l'instant avec SFR dans le 59.

-------------------------- 2023-08-27 22:54:56 +0200 --------------------------
Paramétrage réseau actuel du système:
  AutoTuningLevelLocal: Normal
  CongestionProvider: CUBIC
  EcnCapability: Disabled
  NetworkCategory: Private
  ScalingHeuristics: Disabled
  Timestamps: Allowed
  => Latence TCP max pour une réception à 1 Gbps: 141 ms

Test TCP local (IPv4): téléchargement depuis la Freebox
[!] Echec du test de latence
    En cas d'absence de Freebox, le paramètre --skip-freebox (-F) peut être utilisé pour désactiver le test local

Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
  --> Latence: 11.08 ms                 [gigue: 0.47 ms]
  --> Débit: 105.06 Mo/s (840.50 Mbps)  [fluctuation: 3.56%]

Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
  --> Latence: 10.85 ms                 [gigue: 0.33 ms]
  --> Débit: 118.02 Mo/s (944.12 Mbps)  [fluctuation: 1.00%]
-------------------------- 2023-08-27 22:55:32 +0200 --------------------------

Il me semble que Free n'utilise pas les collectes activées sur les RIP.