Auteur Sujet: Test de débit et de neutralité de l'Internet (Lu 140370 fois)

kgersen · « **Réponse #120 le:** 29 février 2016 à 18:31:22 »

voici la todo list de la v1:

- option "size <value>" with <value> =
Size | SizeDown/SizeUP
Size, SizeDown, SizeUP = numberK or numberM or numberG or numberT (K,M,G,T = 1000 multipliers not 1024)
so "-size 1G/200M" with use 1GB for download (GET) and 200MB for upload (POST)
default value is 10M (= 10M/10M)

- option "-cvs " : display only test results in tabular format, separator is ";"
starting date/time; server url; test parameters (same as -test); computed results; raw curl results; ending date/time

- option '-maxtime <time>': each test will timeout after <time> seconds

- output changes: if no "-cvs" option, the program will display OS version, starting date/time and ending date/time.

kgersen · « **Réponse #121 le:** 29 février 2016 à 18:38:05 »

Citation de: hwti le 29 février 2016 à 18:29:49

Pour les tests d'upload, à la place du fichier temporaire qu'on télécharge, l'idéal serait de passer par un pipe (et '-F "filecontent=@-"'), pour ne pas être limité par le disque sur les connexions très rapides, ou quand le test est exécuté depuis un Raspberry Pi ou similaire ("disque" lent et de petite taille).
Mais ne sais pas ce que ça donnerait comme performance en utilisant la fonction rand() de perl (le /dev/urandom non seulement spécifique à Linux, mais de toute façon pas assez rapide, 25Mo/s sur mon PC par exemple).

y'a quelques temps, j'avais testé avec 'dd' pipé dans un curl mais ce marchait pas bien. essais voir si ca marche (ou /dev/zero avec un max time). après faut penser a Windows et MacOS aussi.

y'a libcurl en perl aussi mais je n'ai pas regarder ce qu'on pouvait faire avec.

Mon but n'est pas d'aller trop loin en Perl. Je veux juste une v1 'propre'. Apres n'importe qui pourra partir sur cette base pour ajouter des trucs.

Ma suite c'est de faire un client en Go ou l'on aura un contrôle plus fin que d'aller 'piloter curl' et ou on pourra optimiser (fastpath) l'upload. En fait le projet c'est que le serveur de débit écrit en Go sera reversible et utilisable en client , a l'instar d'IPerf2/IPerf3.

vivien · « **Réponse #122 le:** 29 février 2016 à 19:07:25 »

Citation de: hwti le 29 février 2016 à 17:33:43

Si on tue curl, il se donne pas les valeurs dont on se sert en sortie.
Mais avec --max-time, si.

J'ai loupé ca dans les nombreuses option de curl.

Du coup, ca serait possible de partir par défaut (si rien n'est mis sur la ligne de commande) par un test avec le fichier de 5Go et un max-time de 8 secondes ?

L'idée c'est que ce soit le plus simple possible pour le grand public (sans mettre d'option)

Citation de: hwti le 29 février 2016 à 18:29:49

Pour les tests d'upload, à la place du fichier temporaire qu'on télécharge, l'idéal serait de passer par un pipe (et '-F "filecontent=@-"'), pour ne pas être limité par le disque sur les connexions très rapides

Ca aussi j'ai pas vu. Ca upload quoi ? une suite de zéro ?

hwti · « **Réponse #123 le:** 29 février 2016 à 20:08:26 »

Citation de: kgersen le 29 février 2016 à 18:38:05

y'a quelques temps, j'avais testé avec 'dd' pipé dans un curl mais ce marchait pas bien. essais voir si ca marche (ou /dev/zero avec un max time). après faut penser a Windows et MacOS aussi.

Un dd pipé fonctionne, mais :
- avec /dev/zero on ne se protège pas d'une éventuelle "optimisation" de la part de l'opérateur, s'il compresse le trafic (sur mobile par exemple), donc avoir du contenu aléatoire (comme les fichiers de tests sur le serveur) est préférable
- ce n'est pas compatible avec Windows effectivement

Mais curl semble lire la totalité du fichier avant l'upload, donc :
- "cat /dev/zero | curl --max-time xx ..." ne fonctionne pas
- avec un dd, tout le contenu généré est mis en RAM

Avec -T- (donc un PUT au lieu d'un POST), on n'a pas cette limitation :
- cat /dev/zero | curl --max-time xx ...
- dd /dev/zero bs=1M count=10 | curl ...

Citation de: kgersen le 29 février 2016 à 18:38:05

y'a libcurl en perl aussi mais je n'ai pas regarder ce qu'on pouvait faire avec.

Je ne sais pas ce que ça donne pour les perfs (surtout en download).

Citation de: vivien le 29 février 2016 à 19:07:25

Ca aussi j'ai pas vu. Ca upload quoi ? une suite de zéro ?

Ca upload stdin. Pour une suite de zéros voir les exemples plus haut.

vivien · « **Réponse #124 le:** 29 février 2016 à 20:18:43 »

Citation de: hwti le 29 février 2016 à 20:08:26

Ca upload stdin.

donc ce que je tape au clavier, non ?

Attention avec les données aléatoires : le débit de données aléatoire est fortement limité (cela sera peut-être meilleur avec les CPU qui ont une instruction spécifique pour générer des données aléatoires)

Citation de: vivien le 16 octobre 2012 à 19:02:59

Comment créer des fichiers arbitrairement lourds pour tester son débit ?

Voici la commande, sous linux pour créer un fichier rempli de zéro, donc facilement compressible :
dd if=/dev/zero of=/tmp/1Mo.zero bs=1KB count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
100000000 octets (100 MB) copiés, 0,911139 s, 110 MB/s
C'est un fichier de 100 Mo, pour un fichier plus gros ou plus petit, il suffit de modifier "count" qui compte le nombre de bloc de 1 Ko.

Voici la même commande, pour créer un fichier rempli de données pseudo-aléatoires donc non compressible :
dd if=/dev/urandom of=/tmp/1Mo.random bs=1KB count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
100000000 octets (100 MB) copiés, 9,44209 s, 10,6 MB/s

hwti · « **Réponse #125 le:** 29 février 2016 à 20:20:50 »

Citation de: vivien le 29 février 2016 à 20:18:43

donc ce que je tape au clavier, non ?

si tu ne pipes rien, oui

Citation de: vivien le 29 février 2016 à 20:18:43

Attention avec les données aléatoires : le débit de données aléatoire est fortement limité

C'est ce que je dis plus haut, le /dev/urandom plafonne à 25Mo/s pour moi.

kgersen · « **Réponse #126 le:** 29 février 2016 à 20:38:57 »

j'ai quasi finit les options.

Je commence a tester le timeout. ca marche bien pour le moment.

je verrais ensuite pour ne plus utiliser de fichiers temporaires en utilisant PUT au lieu d'un POST.

kgersen · « **Réponse #127 le:** 29 février 2016 à 21:05:29 »

voila ce que ca donne avec la nouvelle option timeout:

Code: [Sélectionner]

$ perl neutrality-test.pl -timeout 1 -size 1000M
IPv4+TCP80    +  http  .zip:   826.42 Mb/s (DNS:4ms SYN:3ms GET:4ms Down:995ms:timeout)
IPv4+TCP80    +  http  .jpg:   890.93 Mb/s (DNS:29ms SYN:4ms GET:3ms Down:996ms:timeout)
IPv4+TCP80    +  http  .mp4:   815.12 Mb/s (DNS:12ms SYN:4ms GET:3ms Down:996ms:timeout)
IPv4+TCP80    +  http  .pdf:   859.69 Mb/s (DNS:12ms SYN:4ms GET:3ms Down:996ms:timeout)
IPv4+TCP443   + https  .zip:   654.41 Mb/s (DNS:29ms SYN:5ms GET:31ms Down:968ms:timeout)
IPv4+TCP443   + https  .jpg:   557.36 Mb/s (DNS:61ms SYN:3ms GET:36ms Down:963ms:timeout)
IPv4+TCP554   +  http  .zip:    43.25 Mb/s (DNS:12ms SYN:4ms GET:3ms Down:996ms:timeout)
IPv4+TCP554   +  http  .jpg:    44.04 Mb/s (DNS:12ms SYN:4ms GET:3ms Down:996ms:timeout)
IPv4+TCP554   +  http  .mp4:    41.93 Mb/s (DNS:28ms SYN:4ms GET:4ms Down:995ms:timeout)
IPv4+TCP993   + https  .zip:   548.52 Mb/s (DNS:12ms SYN:4ms GET:36ms Down:963ms:timeout)
IPv4+TCP993   + https  .jpg:   549.19 Mb/s (DNS:13ms SYN:3ms GET:41ms Down:958ms:timeout)
IPv4+TCP1194  + https  .zip:   543.17 Mb/s (DNS:29ms SYN:3ms GET:34ms Down:965ms:timeout)
IPv4+TCP1194  + https  .jpg:   721.58 Mb/s (DNS:12ms SYN:4ms GET:37ms Down:962ms:timeout)
IPv4+TCP6881  +  http  .zip:   822.12 Mb/s (DNS:12ms SYN:4ms GET:4ms Down:995ms:timeout)
IPv4+TCP6881  +  http  .jpg:   814.81 Mb/s (DNS:28ms SYN:4ms GET:3ms Down:996ms:timeout)
IPv4+TCP8080  +  http  .zip:   804.56 Mb/s (DNS:29ms SYN:3ms GET:3ms Down:996ms:timeout)
IPv4+TCP8080  +  http  .jpg:   803.61 Mb/s (DNS:29ms SYN:3ms GET:3ms Down:996ms:timeout)
IPv4+TCP8080  +  http  .mp4:   814.46 Mb/s (DNS:29ms SYN:3ms GET:4ms Down:995ms:timeout)
IPv6+TCP80    +  http  .zip:   176.28 Mb/s (DNS:61ms SYN:12ms GET:6ms Down:994ms:timeout)
IPv6+TCP80    +  http  .jpg:   194.78 Mb/s (DNS:4ms SYN:4ms GET:5ms Down:994ms:timeout)
IPv6+TCP80    +  http  .mp4:   202.25 Mb/s (DNS:29ms SYN:4ms GET:5ms Down:994ms:timeout)
IPv6+TCP443   + https  .zip:   619.69 Mb/s (DNS:4ms SYN:4ms GET:40ms Down:959ms:timeout)
IPv6+TCP554   +  http  .zip:   184.47 Mb/s (DNS:125ms SYN:4ms GET:5ms Down:995ms:timeout)
IPv6+TCP1194  + https  .zip:   593.44 Mb/s (DNS:61ms SYN:4ms GET:38ms Down:961ms:timeout)
IPv6+TCP6881  +  http  .zip:   850.29 Mb/s (DNS:61ms SYN:4ms GET:5ms Down:994ms:timeout)
IPv6+TCP8080  +  http  .zip:   110.61 Mb/s (DNS:125ms SYN:4ms GET:5ms Down:995ms:timeout)
downloading temporary file temp1097-1000m.zip...done.
IPv4+TCP80    +  http  .zip:   208.64 Mb/s (DNS:61ms SYN:3ms POST:3ms Up:997ms:timeout)
downloading temporary file temp1097-1000m.jpg...done.
IPv4+TCP80    +  http  .jpg:   235.30 Mb/s (DNS:4ms SYN:3ms POST:3ms Up:996ms:timeout)
downloading temporary file temp1097-1000m.mp4...done.
IPv4+TCP80    +  http  .mp4:   206.40 Mb/s (DNS:125ms SYN:4ms POST:3ms Up:997ms:timeout)
IPv4+TCP443   + https  .zip:   153.06 Mb/s (DNS:4ms SYN:9ms POST:39ms Up:960ms:timeout)
IPv4+TCP554   +  http  .zip:    56.14 Mb/s (DNS:4ms SYN:8ms POST:9ms Up:990ms:timeout)
IPv4+TCP1194  + https  .zip:   100.11 Mb/s (DNS:125ms SYN:3ms POST:41ms Up:1486ms:timeout)
IPv4+TCP6881  +  http  .zip:   123.36 Mb/s (DNS:4ms SYN:3ms POST:3ms Up:1223ms:timeout)
IPv4+TCP8080  +  http  .zip:   233.72 Mb/s (DNS:4ms SYN:4ms POST:3ms Up:996ms:timeout)
IPv6+TCP80    +  http  .zip:    64.81 Mb/s (DNS:4ms SYN:13ms POST:14ms Up:985ms:timeout)
IPv6+TCP80    +  http  .jpg:    65.01 Mb/s (DNS:4ms SYN:4ms POST:4ms Up:996ms:timeout)
IPv6+TCP80    +  http  .zip:    66.00 Mb/s (DNS:4ms SYN:4ms POST:5ms Up:995ms:timeout)
IPv6+TCP443   + https  .zip:    55.63 Mb/s (DNS:4ms SYN:4ms POST:33ms Up:966ms:timeout)
IPv6+TCP554   +  http  .zip:    81.02 Mb/s (DNS:4ms SYN:4ms POST:5ms Up:995ms:timeout)
IPv6+TCP1194  + https  .zip:    68.12 Mb/s (DNS:4ms SYN:5ms POST:33ms Up:966ms:timeout)
IPv6+TCP6881  +  http  .zip:    91.95 Mb/s (DNS:4ms SYN:4ms POST:5ms Up:995ms:timeout)
IPv6+TCP8080  +  http  .zip:    61.26 Mb/s (DNS:4ms SYN:4ms POST:5ms Up:995ms:timeout)

y'a une nouvelle info a la fin "timeout" ou "full" indiquant si curl finit ou pas le transfert avant le delai.

Je vais fignoler un peu l'affichage. virer les fichiers temporaires si je peux.

J'ai mis a jour le github avec cette version.

l'option -cvs n'est pas implèmentée encore.

a noter : l'option -size support les post-fixes G ou T mais pas le serveur de Vivien donc pour 2G mettre 2000M par exemple.

vivien · « **Réponse #128 le:** 29 février 2016 à 21:10:27 »

Pas de fichier de 2Go, car cela prend pas mal de place en ram (il y a un ramdisque pour mettre ces fichiers, la taille utilisée est de 6,6 Go dont 5Go pour le fichier de 5Go. Mettre un fichier de 2Go aurait fait passer la taille à 8,6Go)

Sinon, pourquoi télécharger 3 fichiers pour l'upload ?

Un seul me semble suffisant, il suffit ensuite de le renommer.

Que que soit l'extension du fichier, c'est les mêmes données aléatoires derrière. la somme du contrôle du fichier .zip est la même que celle du fichier .jpg ou .mp4

Si on ne met aucune option, l'idéal serait de partir en timeout (8 secondes semble pertinent pour laisser le temps à TCP/IP de monter et avoir une moyenne pas trop pourrie).
Pour le fichier upload, il faudrait récupérer la taille téléchargée en http et prendre le fichier disponible sur le serveur avec la taille juste supérieure (donc durée de téléchargement de 8 a 20 secondes) et uploader ce fichier avec timeout. Même avec un débit symétrique, on devrait atteindre le timeout.

kgersen · « **Réponse #129 le:** 29 février 2016 à 23:06:32 »

Citation de: vivien le 29 février 2016 à 21:10:27

Sinon, pourquoi télécharger 3 fichiers pour l'upload ?

Un seul me semble suffisant, il suffit ensuite de le renommer.

Que que soit l'extension du fichier, c'est les mêmes données aléatoires derrière. la somme du contrôle du fichier .zip est la même que celle du fichier .jpg ou .mp4

Le but n’était pas d'être trop spécifique a ton serveur.

En fait pour les types de fichiers ce n'est pas que l'extension qui devrait compter mais aussi le contenu.Si on veut vraiment évaluer les traitements des FAI sur certains types de flux notamment les images et les vidéos (en mobile par exemple) il serait bien de pouvoir passer des vrais fichiers dans la mesure du possible.

Je pensais aussi que ton serveur fournissait des vrais contenus et pas du random.

de toute facon si j'arrive à faire de l'upload sans fichier réel la question ne se posera plus.

hwti · « **Réponse #130 le:** 29 février 2016 à 23:53:33 »

Citation de: vivien le 29 février 2016 à 21:10:27

Pas de fichier de 2Go, car cela prend pas mal de place en ram (il y a un ramdisque pour mettre ces fichiers, la taille utilisée est de 6,6 Go dont 5Go pour le fichier de 5Go. Mettre un fichier de 2Go aurait fait passer la taille à 8,6Go)

Un truc pour ton serveur, si tu as ce qu'il faut pour supporter le btrfs (valable pour une machine ayant /tmp en tmpfs, à ajuster sinon) :

Code: [Sélectionner]

truncate -s 5G /tmp/5G.img
mkfs.btrfs /tmp/5G.img
mount /tmp/5G.img /mnt
dd if=/dev/urandom of=/mnt/4G.dat bs=1M count=4096
cp --reflink=always /mnt/4G.dat /mnt/2G.dat
truncate -s 2G /mnt/2G.dat

Et voilà, les deux fichiers partagent leurs données, on a fait tenir "6Go" dans 4Go de RAM

Il y a certainement moyen d'ajuster la taille des metadata, pour réduire la taille de l'image, mais ça ne sert pas à grand chose puisque les pages non utilisées du /tmp/5G.img se sont pas allouées (le tmpfs n'alloue les pages que quand on écrit dedans).

EDIT: l'exemple utilise btrfs au dessus de loopdev (/dev/loopX) et tmpfs, on peut faire du btrfs au dessus d'un ramdisk (/dev/ramX) à la place (je n'ai pas testé, la première solution est déjà largement assez rapide).

Gwadagamer · « **Réponse #131 le:** 01 mars 2016 à 00:54:54 »

Citation de: hwti le 29 février 2016 à 23:53:33

Un truc pour ton serveur, si tu as ce qu'il faut pour supporter le btrfs (valable pour une machine ayant /tmp en tmpfs, à ajuster sinon) :
Code: [Sélectionner]
truncate -s 5G /tmp/5G.img mkfs.btrfs /tmp/5G.img mount /tmp/5G.img /mnt dd if=/dev/urandom of=/mnt/4G.dat bs=1M count=4096 cp --reflink=always /mnt/4G.dat /mnt/2G.dat truncate -s 2G /mnt/2G.datEt voilà, les deux fichiers partagent leurs données, on a fait tenir "6Go" dans 4Go de RAM
Il y a certainement moyen d'ajuster la taille des metadata, pour réduire la taille de l'image, mais ça ne sert pas à grand chose puisque les pages non utilisées du /tmp/5G.img se sont pas allouées (le tmpfs n'alloue les pages que quand on écrit dedans).

classe le montage pour btrfs .. je suis content de voir que je ne suis pas le seul user de ce système d eficheir.. sous gentoo avec le system de snapshot je ne peut plus m'ne passer juste avant une update