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