Auteur Sujet: Les connexions 10 Gb/s: un vrai défi pour les testeurs de débit (Lu 103123 fois)

alegui · « **Réponse #24 le:** 25 mars 2018 à 21:20:04 »

Citation de: Doku le 25 mars 2018 à 20:33:55

Je ne sais pas trop quoi penser...
Comme il est précisé dès le premier post, une capacité aussi colossale est à la limite du ridicule, car un usage standard pour la majorité des utilisateurs tournant autour de facebook ou youtube ne nécessite pas plus de 10 voire 20mega.
[...]
Du coup, quand on voit ce genre de coup de pub des FAI "à qui ira le plus vite", c'est d'un côté encourageant sur l'évolution des technologies, mais aussi... écoeurant.
Généralement, cela concerne la partie de population qui a déjà 100méga ou plus, et aura encore plus, alors que ceux qui sont à ramasser les restes dans le caniveau, continuent à faire les poubelles des fonds du réseau.
C'est dommage :/

En fibre optique, offrir 100 mb/s ou 10 gb/s ne change pas grand-chose au niveau de l'infrastructure passive, et la consommation moyenne des clients n'est pas beaucoup plus élevée en moyenne : comme tu l'as dit pour Facebook ou YouTube pas besoin de plus de quelques mb/s. Donc si le prix du matériel actif le permet, augmenter le débit maximum commercial n'est pas très difficile, pour un gain de clientèle probablement moins négligeable que le gain pratique pour les clients.
C'est assez rageant pour ceux qui sont en bout de ligne ADSL, mais il faut bien comprendre que c'est beaucoup plus difficile de passer à 100 mb/s sur une paire de fil de cuivre que d'augmenter les débits sur une fibre optique.

[TROLL]Par contre, mesurer des débits très élevés, ça par contre c'est difficile[/TROLL]

Antwan · « **Réponse #25 le:** 25 mars 2018 à 21:20:18 »

Etant donné que c’est le CPU qui est limitant je seraais curieux d’avoir les résultats sur une distribution BSD.

vivien · « **Réponse #26 le:** 25 mars 2018 à 21:21:57 »

BSD devrait vraiment changer qq chose ?

Dans les benchmark c'est pas époustouflant FreeBSD...

Il aurait par contre été pertinent de tester sans les patchs meldown / spectre.

Citation de: Thornhill le 25 mars 2018 à 20:57:30

Je ne comprends pas l'intérêt d'un stockage rapide pour un test de débit : le softs de test n'envoient pas les données dans /dev/null ?

Les tests de débit ne font normalement pas d’accès en lecture /ou écriture sur le disque.

C'est essentiel vu les faibles performances des disques a plateau.

Pour les SSD, attention aux débits théoriques en séquentiel et la pratique
=> je sature un RAID 0 de deux SSD avec un débit en lecture de 100 Mo/s (800 Mb/s)

aem38 · « **Réponse #27 le:** 25 mars 2018 à 21:35:55 »

@Vivien : essai très intéressant. Merci.

C'est quoi la carte mère et le bus utilisé pour la carte 10GbE ? PCIe 3.0 x4 ?
la MTU utilisée ?

EDIT après lecture post.

Optix · « **Réponse #28 le:** 25 mars 2018 à 21:46:43 »

La vraie solution est d'utiliser les WebWorkers JS qui permettent le multithread et donc utiliser l'ensemble des coeurs d'un CPU pour tester le débit.

Après, il y a plusieurs contraintes de façon générale :
- Soit on génère le flux à la volée : il faut générer des données aléatoires (surtout pas de zéros à la suite qui se compressent très facilement), mais ça consomme davantage de CPU
- Soit on lit bêtement un flux qu'on a reçu : dans ce cas, ça prend sur la mémoire, mais consomme moins de CPU.

Le risque de prendre sur la mémoire, c'est que l'OS aura tendance à utiliser le swap, donc des accès disques.

vivien · « **Réponse #29 le:** 25 mars 2018 à 21:55:16 »

Les tests de débit utilisent déja tous les cœurs disponibles.

Le PC utilisé pour réaliser les test est un Dell Inspiron 3847 :

Voici le lscpu :
Architecture: x86_64 Mode(s) opératoire(s) des processeurs : 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) par cœur : 2 Cœur(s) par socket : 2 Socket(s): 1 Nœud(s) NUMA : 1 Identifiant constructeur : GenuineIntel Famille de processeur : 6 Modèle : 60 Model name: Intel(R) Core(TM) i3-4150 CPU @ 3.50GHz Révision : 3 Vitesse du processeur en MHz : 3492.009 CPU max MHz: 3500,0000 CPU min MHz: 800,0000 BogoMIPS: 6984.01 Virtualisation : VT-x Cache L1d : 32K Cache L1i : 32K Cache L2 : 256K Cache L3 : 3072K NUMA node0 CPU(s): 0-3 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti retpoline spec_ctrl tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm arat pln pts

Voici le lspci :
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06) 00:02.0 VGA compatible controller: Intel Corporation 4th Generation Core Processor Family Integrated Graphics Controller (rev 06) 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05) 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5) 00:1c.1 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #2 (rev d5) 00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 (rev d5) 00:1c.4 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #5 (rev d5) 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation C220 Series Chipset Family H81 Express LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05) 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05) 02:00.0 Audio device: Creative Labs Sound Core3D [Sound Blaster Recon3D / Z-Series] (rev 01) 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) 04:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01)

Il manque la carte 10 Gb/s dans ce lscpi. C'est une Carte réseau convergent Ethernet Intel X540-T1 connecté dans le port PCI express 16x de la carte mère.

Thornhill · « **Réponse #30 le:** 25 mars 2018 à 22:18:50 »

Citation de: Optix le 25 mars 2018 à 21:46:43

Après, il y a plusieurs contraintes de façon générale :
- Soit on génère le flux à la volée : il faut générer des données aléatoires (surtout pas de zéros à la suite qui se compressent très facilement), mais ça consomme davantage de CPU

À quel niveau le flux serait compressé ?

Thornhill · « **Réponse #31 le:** 25 mars 2018 à 22:24:25 »

Citation de: Optix le 25 mars 2018 à 21:46:43

Soit on lit bêtement un flux qu'on a reçu : dans ce cas, ça prend sur la mémoire, mais consomme moins de CPU.

Rien n'empêche de renvoyer des millions de fois le même buffer de quelques Mo, ça ne consommera pas grand chose en RAM.
Même chose à la réception : tu réécrases le buffer de l'appel précédent.

hoyohoyo · « **Réponse #32 le:** 25 mars 2018 à 22:32:38 »

Citation de: Thornhill le 25 mars 2018 à 20:57:30

Je ne comprends pas l'intérêt d'un stockage rapide pour un test de débit : le softs de test n'envoient pas les données dans /dev/null ?

si t'as un Disque dur banale 100 mo/sec ou un SSD 500 mo/sec banale tu vas jamais exploiter du 10 Gb/s

Mais avec un ssd M.2 NVMe ex :

Samsung 960 PRO M.2 PCIe NVMe
Taux de transfert maximal en lecture 3500 Mo/s
Taux de transfert maximal en écriture 2100 Mo/s

Là tu vas pouvoir bien exploiter cette vitesse à condition que les serveurs suivent que j'ai de gros doutes là

Optix · « **Réponse #33 le:** 25 mars 2018 à 22:33:40 »

Citation de: Thornhill le 25 mars 2018 à 22:18:50

À quel niveau le flux serait compressé ?

Du serveur web, d'un proxy, etc.

Citation de: Thornhill le 25 mars 2018 à 22:24:25

Rien n'empêche de renvoyer des millions de fois le même buffer de quelques Mo, ça ne consommera pas grand chose en RAM.
Même chose à la réception : tu réécrases le buffer de l'appel précédent.

Si tu renvoies X fois la même chose, tu tombes sur le même problème qu'avant : le flux peut se compresser et faussera les résultats.

En tout cas, je préfère consommer davantage de RAM dans le cadre de speedtest et conserver mes ressources CPU pour les dédier aux chronos et calculs de débits.

PS: attention au multipost, le bouton "éditer" est là pour ça

hwti · « **Réponse #34 le:** 25 mars 2018 à 22:45:26 »

Citation de: Optix le 25 mars 2018 à 21:46:43

- Soit on génère le flux à la volée : il faut générer des données aléatoires (surtout pas de zéros à la suite qui se compressent très facilement), mais ça consomme davantage de CPU

En SSL, pas besoin, à condition d'avoir un serveur bien configuré (pas de compression SSL, mais normalement les navigateur l'ont déjà désactivée à cause des failles, et pas de compression HTTP).
Sinon il faut utiliser Web Crypto (soit pour générer des nombres aléatoires directement, soit éventuellement en chiffrant un bloc avec des clés AES aléatoires), mais les performances doivent pas mal varier selon l'implèmentation.

Cqoicebordel · « **Réponse #35 le:** 25 mars 2018 à 22:57:01 »

Pour éviter les problèmes de CPU et de RAM, un test wget vers /dev/null pourrait être intéressant, non ?
Un truc du genre "wget -O /dev/null http://bouygues.testdebit.info/1G.iso"
(repiqué directement de https://testdebit.info/)