Auteur Sujet: checkFtthFree (test de débit TCP mono-connexion Freebox/Cubic/BBR) (Lu 45825 fois)

kgersen · « **Réponse #312 le:** 28 novembre 2024 à 18:23:18 »

hum ca ressemble quand meme a une histoire de taille de buffers quelque part... (a moins que le peering entre Free et OVH soit hyper saturé...).

Fuzy · « **Réponse #313 le:** 28 novembre 2024 à 19:04:13 »

J'en ai fait 2 de suite ce soir !

Code: [Sélectionner]

running jobs of '#0' (0)...
batch #0:
 Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
 #0|   1.1 Gbps|       0 bps| 7.95|     1.1 GB|           0 B|get https://rbx.proof.ovh.net/files/10Gb.dat (IPv6 - 1.712 ms - HTTP/1.1 - TLS 1.2)

Code: [Sélectionner]

running jobs of '#0' (0)...
batch #0:
 Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
 #0| 844.3 Mbps|       0 bps| 7.97|   840.8 MB|           0 B|get https://rbx.proof.ovh.net/files/10Gb.dat (IPv6 - 11.237 ms - HTTP/1.1 - TLS 1.2)

Fuzy · « **Réponse #314 le:** 29 novembre 2024 à 14:39:29 »

Pour information, j'ai essayé de lancer 2 téléchargements en même temps sur le 2 machines derrière l'Ultra (serveurs pouvant cogner 400 Mo/s*2).... limité définitevement à "300 Mo/s" max entre les 2 machines...
C'est encore moins bien que l'offre pop avec ses 5G partagés.

ouno · « **Réponse #315 le:** 30 novembre 2024 à 14:05:24 »

Citation de: Fuzy le 29 novembre 2024 à 14:39:29

Pour information, j'ai essayé de lancer 2 téléchargements en même temps sur le 2 machines derrière l'Ultra (serveurs pouvant cogner 400 Mo/s*2).... limité définitevement à "300 Mo/s" max entre les 2 machines...
C'est encore moins bien que l'offre pop avec ses 5G partagés.

Il me semblait qu'en multi-connexions sur 1 seule machine tu arrivais bien au max de la ligne. Et là avec 2 machines différentes qui téléchargent depuis le net en même temps (donc avec au moins 2 connexions en simultané) tu n'arrives à avoir que 300Mo/s au total ?

Fuzy · « **Réponse #316 le:** 30 novembre 2024 à 18:25:31 »

Oui c’est ça !

ouno · « **Réponse #317 le:** 20 décembre 2024 à 00:03:40 »

Nouvelle version v0.25: corrige la non reconnaissance des vitesses de lien réseau ayant une virgule

Kazer67 · « **Réponse #318 le:** 28 décembre 2024 à 22:30:20 »

Je viens de faire, outil sympa :

Code: [Sélectionner]

Configuration réseau du système:
  dev.link_speed: 8.0 GT/s PCIe
  dev.link_width: 4
  intf.dev: enp4s0
  intf.mtu: 1500
  intf.qdisc: mq
  intf.qlen: 1000
  link.duplex: full
  link.speed: 10000
  net.core.default_qdisc: fq_codel
  net.core.netdev_budget: 300
  net.core.netdev_budget_usecs: 2000
  net.core.netdev_max_backlog: 1000
  net.core.rmem_max: 7340032
  net.core.wmem_max: 7340032
  net.ipv4.tcp_adv_win_scale: 1
  net.ipv4.tcp_congestion_control: cubic
  net.ipv4.tcp_dsack: 1
  net.ipv4.tcp_ecn: 2
  net.ipv4.tcp_mem: 381795	509060	763590
  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: 1.00 ms			[gigue: 0.22 ms]
  --> Débit: 1.18 Go/s (9.40 Gbps)	[fluctuation: 0.13%]

Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
  --> Latence: 9.74 ms			[gigue: 0.42 ms]
  --> Débit: 401.80 Mo/s (3.21 Gbps)	[fluctuation: 0.83%]
[!] Le compteur "rx_softnet_squeezed" du noyau a été incrémenté de 18 pendant le test.

Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
  --> Latence: 9.02 ms			[gigue: 0.16 ms]
  --> Débit: 421.71 Mo/s (3.37 Gbps)	[fluctuation: 1.55%]
[!] Le compteur "rx_softnet_squeezed" du noyau a été incrémenté de 91 pendant le test.
-------------------------- 2024-12-28 22:27:00 +0100 --------------------------

J'ai pas vu de possibilité de test l'upload, ce qui serait bien (c'est sur l'upload que j'ai un problème en ce moment sur l'Ultra

)

ouno · « **Réponse #319 le:** 29 décembre 2024 à 11:34:39 »

Citation de: Kazer67 le 28 décembre 2024 à 22:30:20

Je viens de faire, outil sympa :

Merci !

Citation de: Kazer67 le 28 décembre 2024 à 22:30:20

Code: [Sélectionner]
[!] Le compteur "rx_softnet_squeezed" du noyau a été incrémenté de 18 pendant le test. [!] Le compteur "rx_softnet_squeezed" du noyau a été incrémenté de 91 pendant le test.

Apparemment ton système n'a pas pu traiter toutes les interruptions logicielles réseau à la volée lors des transferts. Quel processeur as-tu et est-ce que le système était chargé par ailleurs pendant le test ?
Il est possible que tu puisses gagner un peu en performance en allouant plus de temps pour le traitement des interruptions logicielles par cycle d'interrogation NAPI (utiliser le paramètre --suggestions ou -s lors du lancement de checkFtthFree pour avoir les suggestions automatiques qui expliquent comment faire).

Citation de: Kazer67 le 28 décembre 2024 à 22:30:20

J'ai pas vu de possibilité de test l'upload, ce qui serait bien (c'est sur l'upload que j'ai un problème en ce moment sur l'Ultra )

La fonctionnalité de test d'upload est bien présente dans checkFtthFree, il suffit d'ajouter le paramètre de ligne de commande --upload ou -u (voir premier message de ce sujet pour toutes les options disponibles, ou utiliser le paramètre --help ou -h).

Fuzy · « **Réponse #320 le:** 31 décembre 2024 à 09:19:22 »

Citation de: ouno le 29 décembre 2024 à 11:34:39

Merci !
Apparemment ton système n'a pas pu traiter toutes les interruptions logicielles réseau à la volée lors des transferts. Quel processeur as-tu et est-ce que le système était chargé par ailleurs pendant le test ?
Il est possible que tu puisses gagner un peu en performance en allouant plus de temps pour le traitement des interruptions logicielles par cycle d'interrogation NAPI (utiliser le paramètre --suggestions ou -s lors du lancement de checkFtthFree pour avoir les suggestions automatiques qui expliquent comment faire).
La fonctionnalité de test d'upload est bien présente dans checkFtthFree, il suffit d'ajouter le paramètre de ligne de commande --upload ou -u (voir premier message de ce sujet pour toutes les options disponibles, ou utiliser le paramètre --help ou -h).

Passes par PowerShell et essayes ça si le .exe est sur le bureau !

Code: [Sélectionner]

.\desktop/CheckFtthFree.exe -u

ouno · « **Réponse #321 le:** 02 janvier 2025 à 10:00:39 »

Citation de: Fuzy le 31 décembre 2024 à 09:19:22

Passes par PowerShell et essayes ça si le .exe est sur le bureau !

Code: [Sélectionner]
.\desktop/CheckFtthFree.exe -u

Il est sous Linux

MaxLebled · « **Réponse #322 le:** 05 janvier 2025 à 01:58:04 »

Je reviens dans ce fil de discussion suite à un déménagement à Rennes et un passage au SFP+ :

Code: [Sélectionner]

[checkFtthFree v0.25]                           Windows 11 Build 26100 (64-bit)
-------------------------- 2025-01-05 01:51:36 +0100 --------------------------
Configuration réseau du système:
  Adapter.Driver: Intel(R) Ethernet Server Adapter X520-1
  Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
  Adapter.FlowControl: Rx & Tx Enabled
  Adapter.IPChecksumOffloadIPv4: Rx & Tx Enabled
  Adapter.InterruptModeration: Enabled
  Adapter.JumboPacket: Disabled
  Adapter.LinkSpeed: 10 Gbps
  Adapter.LsoV2: Enabled
  Adapter.PcieLinkSpeed: 5.0 GT/s
  Adapter.PcieLinkWidth: 4
  Adapter.PhysicalMediaType: 802.3
  Adapter.ReceiveBuffers: 512
  Adapter.SpeedDuplex: Auto Negotiation
  Adapter.TCPChecksumOffload: Rx & Tx Enabled
  Adapter.TransmitBuffers: 512
  NetProfile.NetworkCategory: Private
  Tcp.AutoTuningLevelLocal: Normal
  Tcp.CongestionProvider: CUBIC
  Tcp.EcnCapability: Disabled
  Tcp.ScalingHeuristics: Disabled
  Tcp.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.39 ms                  [gigue: 0.02 ms]
  --> Débit: 1.17 Go/s (9.35 Gbps)      [fluctuation: 1.06%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 309 pendant le test.

Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
  --> Latence: 8.15 ms                  [gigue: 0.23 ms]
  --> Débit: 237.85 Mo/s (1.90 Gbps)    [fluctuation: 23.18%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 4695 pendant le test.

Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
  --> Latence: 7.52 ms                  [gigue: 0.19 ms]
  --> Débit: 274.81 Mo/s (2.20 Gbps)    [fluctuation: 17.04%]
-------------------------- 2025-01-05 01:52:21 +0100 --------------------------

et ipv6

Code: [Sélectionner]

Test TCP local (IPv4): téléchargement depuis la Freebox
  --> Latence: 0.38 ms                  [gigue: 0.01 ms]
  --> Débit: 1.14 Go/s (9.13 Gbps)      [fluctuation: 2.37%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 786 pendant le test.

Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
  --> Latence: 8.11 ms                  [gigue: 0.33 ms]
  --> Débit: 624.92 Mo/s (5.00 Gbps)    [fluctuation: 12.64%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 32163 pendant le test.

Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
  --> Latence: 7.57 ms                  [gigue: 0.14 ms]
  --> Débit: 768.02 Mo/s (6.14 Gbps)    [fluctuation: 3.63%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 3006 pendant le test.

C'est sur une Delta (R1). C'est pas fou fou ! Mais je ne sais pas si je devrais tenir compte des avertissements concernant "ReceivedDiscardedPackets".

Même à cette heure-ci, nPerf refuse de dépasser 2 Gbps (que ça soit via Chrome/Firefox/l'appli Windows). Quant à Fast.com, ça monte à 8 Gbps pour redescendre très vite à 5-6.

ouno · « **Réponse #323 le:** 05 janvier 2025 à 10:40:46 »

Citation de: MaxLebled le 05 janvier 2025 à 01:58:04

C'est sur une Delta (R1). C'est pas fou fou ! Mais je ne sais pas si je devrais tenir compte des avertissements concernant "ReceivedDiscardedPackets".

C'est pas trop mal quand même pour du mono-connexion. Après ce n'est pas normal effectivement d'avoir le compteur ReceivedDiscardedPackets qui augmente autant pendant les tests.
Cela veut dire que l'interface réseau reçoit des paquets réseau valides qu'elle rejette quand même, en général faute de place dans la mémoire tampon pour les stocker: le système d'exploitation ne vient pas lire cette mémoire tampon assez vite.
Quel processeur as-tu ? Si le processeur est censé pouvoir gérer des transferts multi-gigagbit mono-connexion sans problème il faudrait d'abord regarder côté applications parasites installées qui viendraient pourrir les perfs réseau.
Sinon tu peux essayer d'augmenter la mémoire tampon de réception associée à l'interface (paramètre "Receive Buffers" ou "Mémoire tampon de réception" selon les pilotes), en la passant de 512 à 1024, voire 2048.