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

kgersen · « **Réponse #300 le:** 27 novembre 2024 à 15:43:35 »

c'est clairement un souci apres la freebox, la collecte est saturée ne permettant pas a un flux mono connexion de dépasser 2G ?

bbr2/cubic coté client Windows n'influe que sur l'upload pas le download.

du coup en bbr2, t'as combien en upload mono:

Code: [Sélectionner]

./checkFtthFree.exe -FIu(ou avec nspeed cf précedemment).

Fuzy · « **Réponse #301 le:** 27 novembre 2024 à 18:26:03 »

Citation de: kgersen le 27 novembre 2024 à 15:43:35

du coup en bbr2, t'as combien en upload mono:

Code: [Sélectionner]

[checkFtthFree v0.23]                           Windows 11 Build 26100 (64-bit)
-------------------------- 2024-11-27 17:18:08 +0100 --------------------------
Configuration réseau du système:
  Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
  Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
  Adapter.FlowControl: Rx et Tx activées
  Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
  Adapter.InterruptModeration: Activé(e)
  Adapter.JumboPacket: Désactivé(e)
  Adapter.LinkSpeed: 10 Gbps
  Adapter.LsoV2: Activé(e)
  Adapter.PcieLinkSpeed: 5.0 GT/s
  Adapter.PcieLinkWidth: 4
  Adapter.PhysicalMediaType: 802.3
  Adapter.ReceiveBuffers: 512
  Adapter.SpeedDuplex: Négociation automatique
  Adapter.TCPChecksumOffload: Rx et Tx activées
  Adapter.TransmitBuffers: 512
  NetProfile.NetworkCategory: Private
  Tcp.AutoTuningLevelLocal: Normal
  Tcp.CongestionProvider: BBR2
  Tcp.EcnCapability: Disabled
  Tcp.ScalingHeuristics: Disabled
  Tcp.Timestamps: Allowed
  => Latence TCP max pour une réception à 1 Gbps: 141 ms

Test TCP Internet (IPv4): envoi vers l'AS 12876 (Scaleway) [BBR2]
  --> Latence: 9.28 ms                  [gigue: 0.23 ms]
  --> Débit: 325.97 Mo/s (2.61 Gbps)    [fluctuation: 11.26%]
-------------------------- 2024-11-27 17:18:25 +0100 --------------------------

kgersen · « **Réponse #302 le:** 27 novembre 2024 à 18:31:24 »

au moins c'est cohérent

bien que t'avais 3.2 Gbps avec nspeed non:

Code: [Sélectionner]

batch upload mono:
 Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
 #1|      0 bps|    3.2 Gbps| 8.00|        0 B|        3.2 GB|post http://appliwave.testdebit.info/ul/ 10.7 GB (IPv6 - 8.468 ms -  - )

Fuzy · « **Réponse #303 le:** 27 novembre 2024 à 18:33:16 »

Code: [Sélectionner]

batch upload mono:
 Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
 #1|      0 bps|    3.7 Gbps| 8.00|        0 B|        3.7 GB|post http://appliwave.testdebit.info/ul/ 10.7 GB (IPv6 - 8.958 ms -  - )

Oui !

Fuzy · « **Réponse #304 le:** 27 novembre 2024 à 18:34:02 »

On fait quoi maintenant

kgersen · « **Réponse #305 le:** 27 novembre 2024 à 18:41:37 »

pas grand chose le probleme est sur la collecte au dela de la freebox. Faudrait tester chez un voisin proche pour confirmer.

Fuzy · « **Réponse #306 le:** 27 novembre 2024 à 18:50:35 »

je me vois mal faire du porte à porte avec ma tour sous le bras dans le quartier !

Même en changeant de FAI, je risque d'avoir le même problème ?

ouno · « **Réponse #307 le:** 27 novembre 2024 à 19:03:29 »

Citation de: kgersen le 27 novembre 2024 à 15:43:35

la collecte est saturée ne permettant pas a un flux mono connexion de dépasser 2G ?

Je pense pas que ce soit ça vu que la limite est hyper stable et infranchissable, quelle que soit l'heure de la journée. Et le débit en CUBIC est quasi identique à celui en BBR.

Ca ressemble plus au style de problème qui avait touché les ONU v2 à l'époque et qui avait été corrigé par Free par une mise à jour.
Donc peut-être l'ONU interne de la box / SFP 10G-EPON, ou un composant sur le réseau de collecte...

ouno · « **Réponse #308 le:** 27 novembre 2024 à 19:08:51 »

Citation de: kgersen le 27 novembre 2024 à 18:31:24

au moins c'est cohérent bien que t'avais 3.2 Gbps avec nspeed non:

Et même encore plus ici:

Citation de: Fuzy le 24 novembre 2024 à 15:21:59

Code: [Sélectionner]
batch upload mono: Id| Read speed| Write speed| Time| Bytes read| Bytes written|command #1| 0 bps| 4.7 Gbps| 8.00| 0 B| 4.7 GB|post http://appliwave.testdebit.info/ul/ 10.7 GB (IPv6 - 8.495 ms - - )

(le serveur appliwave est plus performant pour les tests d'upload)

kgersen · « **Réponse #309 le:** 27 novembre 2024 à 20:55:26 »

Citation de: ouno le 27 novembre 2024 à 19:03:29

Je pense pas que ce soit ça vu que la limite est hyper stable et infranchissable, quelle que soit l'heure de la journée. Et le débit en CUBIC est quasi identique à celui en BBR.

Ca ressemble plus au style de problème qui avait touché les ONU v2 à l'époque et qui avait été corrigé par Free par une mise à jour.
Donc peut-être l'ONU interne de la box / SFP 10G-EPON, ou un composant sur le réseau de collecte...

j'avoue je suis perplexe

.

"limite est stable et infranchissable" pour une latence donnée ou pas ?

tu peux tester avec un serveur dans l'Est ?

Code: [Sélectionner]

.\nspeed.exe get http://rbx.proof.ovh.net/files/10Gb.dat

ouno · « **Réponse #310 le:** 27 novembre 2024 à 21:23:05 »

Nouvelle version v0.24, qui ne contient que des ajouts pour les systèmes Linux / *BSD / macOS:

[Linux] Prise en charge de la vérification du taux de transfert de l'interface PCI Express par rapport à la vitesse du lien réseau
[*BSD/macOS] Prise en charge du contrôle des compteurs d'erreurs sur l'interface réseau pendant les tests
[Linux/*BSD/macOS] Beaucoup de nouveaux paramètres et infos réseau affichés (liste complète sur la page de release)

Fuzy · « **Réponse #311 le:** 28 novembre 2024 à 07:28:53 »

Done !

Code: [Sélectionner]

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