Chez moi Windows a souvent des soucis en local pour les vitesses de plusieurs Gbps.
checkFtthFree, curl et meme nspeed ont ce probleme.
J'ai fait quelque tests avec nspeed sur une machine Windows 11 (cpu 32 cores Ryzen 9 3950x) vs une machine Linux bien moins puissante (cpu 4 cores Intel i3-8109U)
Windows: curl et nspeed
max 6.8 Gbps environ avec un core a 100%, checkFtthFree
5.35 GbpsLinux: curl et nspeed 9,4 Gbps (max de l'interface 10G) et un core a 60%, checkFtthFree 8.75 Gbps
Si on regarde les compteurs de lecture (visible avec l'option -verbose sur nspeed).
Windows:
RCount=360196
RSize=29809
Linux:
RCount=270676
RSize=39668
Windows utilise un plus petit tampon (27k vs 39k) donc plus d'itérations de lecture (380k contre 270k) donc saturation d'un core de cpu ? c'est la seule explication que je vois pour le moment mais j'en suis pas certain non plus...(et franchement l'écart n'est pas énorme).
checkFtthFree et curl donnent des comportement similaires mais je n'ai pas accès aux compteurs.
pour checkFttFree, il serait bien d'ajouter si possible la valeur de ces compteurs de lecture (nombre d'appels du callback et taille moyenne du morceaux reçus) pour voir si c'est bien de la que le problème vient. Eventuellement aussi la mesure de la charge cpu pendant le test.
Pour être complet, voici les mêmes tests avec checkFtthFree:
sur le Linux:
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.22 ms [gigue: 0.23 ms]
--> Débit: 1.08 Go/s (8.66 Gbps) [fluctuation: 6.96%]
bien qu'on atteigne pas 9,4 Gbps de moyenne on atteint bien le max a un moment (monitoring de nspeed pendant checkFtthFree):
pour référence, même machine, même condition avec curl ou nspeed (on constate une stabilité plus grande et moins d'utilisation cpu qu'avec checkFtthFree):
(commande = curl -o /dev/null
http://212.27.38.253:8095/fixed/10G)
ps: ces graphes mesurent le débit directement au niveau de l'interface dont sans l'overhead des couches IP+TCP+HTTP (10Gbps sur le graphe ~= 9,4 Gbps au niveau des applications donc).
pour référence les infos du Linux:
Paramétrage réseau actuel du système:
net.core.default_qdisc: fq_codel
net.core.rmem_max: 134217728
net.core.wmem_max: 134217728
net.ipv4.tcp_adv_win_scale: 1
net.ipv4.tcp_congestion_control: bbr
net.ipv4.tcp_mem: 92367 123159 184734
net.ipv4.tcp_no_metrics_save: 0
net.ipv4.tcp_rmem: 4096 87380 134217728
net.ipv4.tcp_sack: 1
net.ipv4.tcp_timestamps: 1
net.ipv4.tcp_window_scaling: 1
net.ipv4.tcp_wmem: 4096 65536 134217728
=> Latence TCP max pour une réception à 1 Gbps: 566 ms
=> Latence TCP max pour une émission à 700 Mbps: 1131 msSur le Windows:
[checkFtthFree v0.12] Windows 10 Build 22624 (64-bit)
-------------------------- 2023-03-24 18:15:33 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: BBR2
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
--> Latence: 0.48 ms [gigue: 0.02 ms]
--> Débit: 669.07 Mo/s (5.35 Gbps) [fluctuation: 2.68%]
-------------------------- 2023-03-24 18:15:51 +0100 --------------------------
Débits fibre Free