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

kgersen · « **Réponse #108 le:** 28 février 2016 à 14:42:12 »

Le port 554 est souvent 'trifouillé' par les FAI. C'est le port utilisé pour RTSP donc par Realplayer, la TV live en IP , les webcam réseau, etc
Bref pas mal de truc video temp réel. C'un protocol de contrôle et pas de transport donc les flux video ne passent sur ce port. En general il passe peu de choses, des échanges très courts mais souvent très prioritaires. Il se peut qu'un FAI priorise vraiment ce port mais en contrepartie en limite le débit ou le contenu pour éviter les abus.

Donc si le FAI inspect le flux , il se peut qu'il bride voir coupe si ce n'est pas le bon protocol dedans.
Toutefois ca peut être aussi un équipement plus local comme une box ou un PC qui fasse se bridage et pas le réseau du FAI.

Peut-etre un test en HTTPS sur le 554 permettra d'en savoir plus mais https://3.testdebit.info:554 n'est pas opérationnel.

ctressens · « **Réponse #109 le:** 28 février 2016 à 15:00:57 »

Bonjour à tous,

Est-ce que vous savez si il existe un équivalent de cet outil pour mesurer la neutralité d'une connexion sous Linux ?

(dites moi si c'est HS)

Merci,

kgersen · « **Réponse #110 le:** 28 février 2016 à 15:41:42 »

Citation de: ctressens le 28 février 2016 à 15:00:57

Bonjour à tous,

Est-ce que vous savez si il existe un équivalent de cet outil pour mesurer la neutralité d'une connexion sous Linux ?

(dites moi si c'est HS)

Merci,

le .bat n'utilise que curl qui est dispo sous linux aussi.

au pire essai avec wine:

(pre-requis: unzip et curl)

Code: [Sélectionner]

mkdir test-neutra
cd test-neutra
wget https://lafibre.info/testdebit/curl/test-neutralite.zip
unzip test-neutralite.zip
wine cmd.exe /c test-neutralite.bat

mais il faut un environnent graphique (session X11) sinon wine risque de ne pas être content.

pour des Linux serveur sans X11, ~~il faut un dosbox ou~~ (errata: dosbox utilise X11 aussi) réécrire le .bat en bash par exemple.

ctressens · « **Réponse #111 le:** 28 février 2016 à 16:48:07 »

Citation de: kgersen le 28 février 2016 à 15:41:42

le .bat n'utilise que curl qui est dispo sous linux aussi.

au pire essai avec wine:

(pre-requis: unzip et curl)
Code: [Sélectionner]
mkdir test-neutra cd test-neutra wget https://lafibre.info/testdebit/curl/test-neutralite.zip unzip test-neutralite.zip wine cmd.exe /c test-neutralite.batmais il faut un environnent graphique (session X11) sinon wine risque de ne pas être content.

pour des Linux serveur sans X11, ~~il faut un dosbox ou~~ (errata: dosbox utilise X11 aussi) réécrire le .bat en bash par exemple.

OK, je vais essayer.

Merci de ta réponse !

kgersen · « **Réponse #112 le:** 28 février 2016 à 22:36:30 »

bon j'ai réécrit le .bat de Vivien en Perl (ca m'a rajeunit, ca faisait bien 15 ans que j'avais pas fait autant de Perl

.

voila ce que ca donne sur un ubuntu 14.04 (ma connexion est en 1G/250M):

Code: [Sélectionner]

$ perl neutrality-test.pl -size 200M
IPv4+TCP80  +http .zip: 922.19 Mb/s (DNS:4ms SYN:4ms GET:3ms Down:1735ms)
IPv4+TCP80  +http .jpg: 925.93 Mb/s (DNS:4ms SYN:4ms GET:3ms Down:1728ms)
IPv4+TCP80  +http .mp4: 894.85 Mb/s (DNS:4ms SYN:4ms GET:3ms Down:1788ms)
IPv4+TCP80  +http .pdf: 925.93 Mb/s (DNS:4ms SYN:4ms GET:3ms Down:1728ms)
IPv4+TCP443  +https .zip: 619.20 Mb/s (DNS:4ms SYN:3ms GET:35ms Down:2584ms)
IPv4+TCP443  +https .jpg: 618.24 Mb/s (DNS:4ms SYN:3ms GET:39ms Down:2588ms)
IPv4+TCP554  +http .zip: 45.65 Mb/s (DNS:4ms SYN:3ms GET:5ms Down:35047ms)
IPv4+TCP554  +http .jpg: 45.34 Mb/s (DNS:253ms SYN:4ms GET:3ms Down:35286ms)
IPv4+TCP554  +http .mp4: 45.41 Mb/s (DNS:125ms SYN:3ms GET:4ms Down:35232ms)
IPv4+TCP993  +https .zip: 588.88 Mb/s (DNS:125ms SYN:4ms GET:37ms Down:2717ms)
IPv4+TCP993  +https .jpg: 618.48 Mb/s (DNS:4ms SYN:3ms GET:36ms Down:2587ms)
IPv4+TCP1194  +https .zip: 618.00 Mb/s (DNS:4ms SYN:3ms GET:39ms Down:2589ms)
IPv4+TCP1194  +https .jpg: 613.97 Mb/s (DNS:4ms SYN:3ms GET:36ms Down:2606ms)
IPv4+TCP6881  +http .zip: 922.19 Mb/s (DNS:4ms SYN:4ms GET:3ms Down:1735ms)
IPv4+TCP6881  +http .jpg: 916.38 Mb/s (DNS:12ms SYN:4ms GET:3ms Down:1746ms)
IPv4+TCP8080  +http .zip: 925.93 Mb/s (DNS:4ms SYN:4ms GET:3ms Down:1728ms)
IPv4+TCP8080  +http .jpg: 925.93 Mb/s (DNS:4ms SYN:3ms GET:3ms Down:1728ms)
IPv4+TCP8080  +http .mp4: 878.16 Mb/s (DNS:4ms SYN:5ms GET:3ms Down:1822ms)
IPv6+TCP80  +http .zip: 425.08 Mb/s (DNS:12ms SYN:12ms GET:5ms Down:3764ms)
IPv6+TCP80  +http .jpg: 372.87 Mb/s (DNS:4ms SYN:5ms GET:6ms Down:4291ms)
IPv6+TCP80  +http .mp4: 430.22 Mb/s (DNS:4ms SYN:4ms GET:5ms Down:3719ms)
IPv6+TCP443  +https .zip: 650.67 Mb/s (DNS:4ms SYN:4ms GET:42ms Down:2459ms)
IPv6+TCP554  +http .zip: 424.97 Mb/s (DNS:4ms SYN:4ms GET:4ms Down:3765ms)
IPv6+TCP1194  +https .zip: 627.45 Mb/s (DNS:4ms SYN:5ms GET:39ms Down:2550ms)
IPv6+TCP6881  +http .zip: 406.30 Mb/s (DNS:4ms SYN:4ms GET:5ms Down:3938ms)
IPv6+TCP8080  +http .zip: 454.03 Mb/s (DNS:4ms SYN:4ms GET:5ms Down:3524ms)
IPv4+TCP80  +http .zip: 238.13 Mb/s (DNS:4ms SYN:3ms POST:3ms Up:6719ms)
IPv4+TCP80  +http .jpg: 238.24 Mb/s (DNS:4ms SYN:3ms POST:4ms Up:6716ms)
IPv4+TCP80  +http .mp4: 238.10 Mb/s (DNS:4ms SYN:3ms POST:3ms Up:6720ms)
IPv4+TCP443  +https .zip: 237.00 Mb/s (DNS:4ms SYN:3ms POST:30ms Up:6751ms)
IPv4+TCP554  +http .zip: 56.38 Mb/s (DNS:12ms SYN:4ms POST:4ms Up:28379ms)
IPv4+TCP1194  +https .zip: 233.68 Mb/s (DNS:125ms SYN:3ms POST:31ms Up:6847ms)
IPv4+TCP6881  +http .zip: 238.27 Mb/s (DNS:4ms SYN:4ms POST:3ms Up:6715ms)
IPv4+TCP8080  +http .zip: 239.66 Mb/s (DNS:4ms SYN:3ms POST:3ms Up:6676ms)
IPv6+TCP80  +http .zip: 52.82 Mb/s (DNS:29ms SYN:14ms POST:4ms Up:30293ms)
IPv6+TCP80  +http .jpg: 53.12 Mb/s (DNS:4ms SYN:4ms POST:5ms Up:30120ms)
IPv6+TCP80  +http .zip: 79.37 Mb/s (DNS:4ms SYN:4ms POST:4ms Up:20158ms)
IPv6+TCP443  +https .zip: 51.00 Mb/s (DNS:4ms SYN:4ms POST:34ms Up:31374ms)
IPv6+TCP554  +http .zip: 77.78 Mb/s (DNS:4ms SYN:5ms POST:4ms Up:20571ms)
IPv6+TCP1194  +https .zip: 55.01 Mb/s (DNS:4ms SYN:5ms POST:35ms Up:29088ms)
IPv6+TCP6881  +http .zip: 48.27 Mb/s (DNS:4ms SYN:4ms POST:5ms Up:33148ms)
IPv6+TCP8080  +http .zip: 59.15 Mb/s (DNS:4ms SYN:4ms POST:5ms Up:27049ms)
removing file temp31023-200.zip
removing file temp31023-200.jpg
removing file temp31023-200.mp4

Le script n'est pas tout a fait fini mais j’arrête la pour ce soir je fatigue

j'ai rajouté des options et la possibilité d'entrer un test manuellement.

Le projet est sur github : https://github.com/kgersen/neutrality-test (j'ai "défrancisé", désolé mais je code tout en anglais par défaut).

Le script perl directement ici : https://raw.githubusercontent.com/kgersen/neutrality-test/master/neutrality-test.pl

Pour le moment la taille est la meme en upload et en download. cela changera.

Je pense avoir un version 1.0 d'ici demain soir.

Ce script utilise pour le moment 'en dur' le serveur 3.testdebit.info et des tailles fixes. Le but a terme est d'en faire un client pour un serveur de speedtest un peu particulier que je suis en train développer (avec quelques mois de retard...) et qui permettra de d’envoyer ou recevoir des fichiers de taille arbitraire et de contenu arbitraire tout en échantillonnant dans le temps les stats avancées de TCP. A terme aussi un client web est prévu pour faire ces tests depuis un navigateur.

ctressens · « **Réponse #113 le:** 28 février 2016 à 23:18:34 »

Citation de: kgersen le 28 février 2016 à 22:36:30

bon j'ai réécrit le .bat de Vivien en Perl (ca m'a rajeunit, ca faisait bien 15 ans que j'avais pas fait autant de Perl .

voila ce que ca donne sur un ubuntu 14.04 (ma connexion est en 1G/250M):

Code: [Sélectionner]
$ perl neutrality-test.pl -size 200M IPv4+TCP80 +http .zip: 922.19 Mb/s (DNS:4ms SYN:4ms GET:3ms Down:1735ms) IPv4+TCP80 +http .jpg: 925.93 Mb/s (DNS:4ms SYN:4ms GET:3ms Down:1728ms) IPv4+TCP80 +http .mp4: 894.85 Mb/s (DNS:4ms SYN:4ms GET:3ms Down:1788ms) IPv4+TCP80 +http .pdf: 925.93 Mb/s (DNS:4ms SYN:4ms GET:3ms Down:1728ms) IPv4+TCP443 +https .zip: 619.20 Mb/s (DNS:4ms SYN:3ms GET:35ms Down:2584ms) IPv4+TCP443 +https .jpg: 618.24 Mb/s (DNS:4ms SYN:3ms GET:39ms Down:2588ms) IPv4+TCP554 +http .zip: 45.65 Mb/s (DNS:4ms SYN:3ms GET:5ms Down:35047ms) IPv4+TCP554 +http .jpg: 45.34 Mb/s (DNS:253ms SYN:4ms GET:3ms Down:35286ms) IPv4+TCP554 +http .mp4: 45.41 Mb/s (DNS:125ms SYN:3ms GET:4ms Down:35232ms) IPv4+TCP993 +https .zip: 588.88 Mb/s (DNS:125ms SYN:4ms GET:37ms Down:2717ms) IPv4+TCP993 +https .jpg: 618.48 Mb/s (DNS:4ms SYN:3ms GET:36ms Down:2587ms) IPv4+TCP1194 +https .zip: 618.00 Mb/s (DNS:4ms SYN:3ms GET:39ms Down:2589ms) IPv4+TCP1194 +https .jpg: 613.97 Mb/s (DNS:4ms SYN:3ms GET:36ms Down:2606ms) IPv4+TCP6881 +http .zip: 922.19 Mb/s (DNS:4ms SYN:4ms GET:3ms Down:1735ms) IPv4+TCP6881 +http .jpg: 916.38 Mb/s (DNS:12ms SYN:4ms GET:3ms Down:1746ms) IPv4+TCP8080 +http .zip: 925.93 Mb/s (DNS:4ms SYN:4ms GET:3ms Down:1728ms) IPv4+TCP8080 +http .jpg: 925.93 Mb/s (DNS:4ms SYN:3ms GET:3ms Down:1728ms) IPv4+TCP8080 +http .mp4: 878.16 Mb/s (DNS:4ms SYN:5ms GET:3ms Down:1822ms) IPv6+TCP80 +http .zip: 425.08 Mb/s (DNS:12ms SYN:12ms GET:5ms Down:3764ms) IPv6+TCP80 +http .jpg: 372.87 Mb/s (DNS:4ms SYN:5ms GET:6ms Down:4291ms) IPv6+TCP80 +http .mp4: 430.22 Mb/s (DNS:4ms SYN:4ms GET:5ms Down:3719ms) IPv6+TCP443 +https .zip: 650.67 Mb/s (DNS:4ms SYN:4ms GET:42ms Down:2459ms) IPv6+TCP554 +http .zip: 424.97 Mb/s (DNS:4ms SYN:4ms GET:4ms Down:3765ms) IPv6+TCP1194 +https .zip: 627.45 Mb/s (DNS:4ms SYN:5ms GET:39ms Down:2550ms) IPv6+TCP6881 +http .zip: 406.30 Mb/s (DNS:4ms SYN:4ms GET:5ms Down:3938ms) IPv6+TCP8080 +http .zip: 454.03 Mb/s (DNS:4ms SYN:4ms GET:5ms Down:3524ms) IPv4+TCP80 +http .zip: 238.13 Mb/s (DNS:4ms SYN:3ms POST:3ms Up:6719ms) IPv4+TCP80 +http .jpg: 238.24 Mb/s (DNS:4ms SYN:3ms POST:4ms Up:6716ms) IPv4+TCP80 +http .mp4: 238.10 Mb/s (DNS:4ms SYN:3ms POST:3ms Up:6720ms) IPv4+TCP443 +https .zip: 237.00 Mb/s (DNS:4ms SYN:3ms POST:30ms Up:6751ms) IPv4+TCP554 +http .zip: 56.38 Mb/s (DNS:12ms SYN:4ms POST:4ms Up:28379ms) IPv4+TCP1194 +https .zip: 233.68 Mb/s (DNS:125ms SYN:3ms POST:31ms Up:6847ms) IPv4+TCP6881 +http .zip: 238.27 Mb/s (DNS:4ms SYN:4ms POST:3ms Up:6715ms) IPv4+TCP8080 +http .zip: 239.66 Mb/s (DNS:4ms SYN:3ms POST:3ms Up:6676ms) IPv6+TCP80 +http .zip: 52.82 Mb/s (DNS:29ms SYN:14ms POST:4ms Up:30293ms) IPv6+TCP80 +http .jpg: 53.12 Mb/s (DNS:4ms SYN:4ms POST:5ms Up:30120ms) IPv6+TCP80 +http .zip: 79.37 Mb/s (DNS:4ms SYN:4ms POST:4ms Up:20158ms) IPv6+TCP443 +https .zip: 51.00 Mb/s (DNS:4ms SYN:4ms POST:34ms Up:31374ms) IPv6+TCP554 +http .zip: 77.78 Mb/s (DNS:4ms SYN:5ms POST:4ms Up:20571ms) IPv6+TCP1194 +https .zip: 55.01 Mb/s (DNS:4ms SYN:5ms POST:35ms Up:29088ms) IPv6+TCP6881 +http .zip: 48.27 Mb/s (DNS:4ms SYN:4ms POST:5ms Up:33148ms) IPv6+TCP8080 +http .zip: 59.15 Mb/s (DNS:4ms SYN:4ms POST:5ms Up:27049ms) removing file temp31023-200.zip removing file temp31023-200.jpg removing file temp31023-200.mp4
Le script n'est pas tout a fait fini mais j’arrête la pour ce soir je fatigue
j'ai rajouté des options et la possibilité d'entrer un test manuellement.

Le projet est sur github : https://github.com/kgersen/neutrality-test (j'ai "défrancisé", désolé mais je code tout en anglais par défaut).

Le script perl directement ici : https://raw.githubusercontent.com/kgersen/neutrality-test/master/neutrality-test.pl

Pour le moment la taille est la meme en upload et en download. cela changera.

Je pense avoir un version 1.0 d'ici demain soir.

Ce script utilise pour le moment 'en dur' le serveur 3.testdebit.info et des tailles fixes. Le but a terme est d'en faire un client pour un serveur de speedtest un peu particulier que je suis en train développer (avec quelques mois de retard...) et qui permettra de d’envoyer ou recevoir des fichiers de taille arbitraire et de contenu arbitraire tout en échantillonnant dans le temps les stats avancées de TCP. A terme aussi un client web est prévu pour faire ces tests depuis un navigateur.

Wow, ça c'est du boulot !

Merci beaucoup !

kgersen · « **Réponse #114 le:** 29 février 2016 à 16:09:21 »

Quelques détails sur les options:

-size taille
spécifie la taille des tests. La taille par défaut est 10M.
Les tailles valides sur le serveur de Vivien sont :
1M 2M 5M 10M 20M 50M 100M 200M 500M 1G 5G
exemple:

Code: [Sélectionner]

perl neutrality-test.pl -size 1Gpour le moment c'est la meme taille en download et en upload mais au besoin on peut limiter le sens, voir plus apres.

-test "IP PORT PROTO TYPE COMMAND"
permet de faire un test unique.

par exemple si on veut juste tester le download d'un jpg de 100Mo sur le port 554 en HTTP, en IPv4:

Code: [Sélectionner]

perl neutrality-test.pl -test "4 554 http .jpg GET" -size 100M
le format est :
-test "IP PORT PROTO TYPE COMMAND" avec : IP = 4 ou 6 PORT = un n° de port TCP PROTO= http https (voir FTP ou autre si le serveur en face le support) TYPE = une extention de fichier (le serveur de Vivien supporte: .zip .jpg, .mp4, .pdf) COMMAND = GET ou POST (GET = download, POST = upload)
Il faut que la combinaison de valeurs soit supportée par le serveur. il n'y pas de contrôle donc ca fera une tentative et une erreur.

Si on ne met pas d'option "-test", tout les tests prédéfinis par Vivien sont lancés sauf si ajoute :
l'option '-ul' pour ne faire que les tests d'upload (POST)
l'option '-dl' pour ne faire que les tests de download (GET)

Par défaut les fichiers temporaires pour l'upload sont stockés dans le répertoire courant.
On peut spécifier un répertoire différent avec l'option "-temppath chemin" (ce n'est pas encore testé intensivement).

On peut aussi changer de serveur avec l'option -server nom_du_serveur (idem pas testé)

Et finalement, pour voir ce qui se passe en détail il y a l'option -debug

Par ailleurs pour éviter de mettre a jour le script manuellement on peut directement l’exécuter depuis github:

Code: [Sélectionner]

curl https://raw.githubusercontent.com/kgersen/neutrality-test/master/neutrality-test.pl | perl - [options]par exemple:

Code: [Sélectionner]

curl https://raw.githubusercontent.com/kgersen/neutrality-test/master/neutrality-test.pl | perl - -test "4 554  http  .jpg GET" -size 100M

hwti · « **Réponse #115 le:** 29 février 2016 à 16:56:16 »

Citation de: kgersen le 29 février 2016 à 16:09:21

pour le moment c'est la meme taille en download et en upload mais au besoin on peut limiter le sens, voir plus apres.

On pourrait avoir un mode qui se baserait sur une durée plutôt qu'une taille : on prend les plus gros fichiers possible, et on ajoute l'option --max-time de curl.

vivien · « **Réponse #116 le:** 29 février 2016 à 17:00:45 »

La durée c'est idéal, mais je n'ai pas trouvé comment faire... j'ai hésité en lançant un sleep en parallèle qui va killer le process

Merci kgersen.

J'arrive un peu tard, mais mon script Windows est issu d'une simplification d'un script perl linux que j'avais réalisé il y a plusieurs années, mais mal écrit (j'ai un peu honte)
=> https://lafibre.info/testdebit/curl/test-neutralite.pl

Voici mon script (qui sais en option mettre les données dans une base MySQL - la commande SQL pour créer la base est indiquée dans le script.)

Dans les idées qu'il faudrait reprendre, mais codées de façon propre, c'est le détail des anomalies rencontrées qui sont dans le rapport détaillé qui est dans /tmp/test-neutralite.log
(ces données ne doivent pas être récupérées pour tous les Linux correctement - car mon script est mal codé, cela fonctionne bien sous Ubuntu 14.04 a 15.10)

le lancement de mon script se fait avec uniquement la taille (en Mo) : ./test-neutralite.pl 100 10 pour utiliser un fichier de 100Mo en down et 10Mo en up

Citation de: kgersen le 29 février 2016 à 16:09:21

Les tailles valides sur le serveur de Vivien sont :
1M 2M 5M 10M 20M 50M 100M 200M 500M 1G 5G

En fait, je n'avais pas de place pour le mettre dans le test batch, mais il y a plus de choix :

1ko 2ko 5ko 10ko 20ko 50ko 100ko 200ko 500ko 1Mo 2Mo 5Mo 10Mo 20Mo 30Mo 50Mo 100Mo 200Mo 500Mo 1000Mo 5000Mo

Citation de: kgersen le 29 février 2016 à 16:09:21

TYPE = une extention de fichier (le serveur de Vivien supporte: .zip .jpg, .mp4, .pdf)

Il support bien plus, voici les extensions proposées, pour toutes les tailles :

Code: [Sélectionner]

.7z   .divx  .iso   .msi   .raw      .tar.xz  .wmv
.aac  .dmg   .jpeg  .odp   .rmvb     .tgz     .woff2
.aif  .doc   .jpg   .ods   .rnd      .txt     .xls
.apk  .docx  .mka   .odt   .rpm      .uu      .xlsx
.asf  .exe   .mks   .ova   .sea      .vivien  .xvid
.au   .flv   .mkv   .pdf   .sit      .vqf     .xz
.avi  .gif   .mov   .png   .svg      .wav     .zip
.bin  .gz    .mp3   .ppt   . swf      .webm
.bz2  .hqx   .mp4   .pptx  .tar      .webp
.deb  .html  .mpg   .rar   .tar.bz2  .wma

Une petite suggestion : serait-il possible d'ordonner les résultats pour que tout soit aligné (comme dans mon script linux - je ne savais pas le faire en batch)

La date et l'heure au début et a la fin du script m'a été demandé pour qu'on ait l'info dans les copies d'écran et montrer que le cela a été long. Je pense que c'est intéressant à rajouter (même mtr rajoute la date de prise du test en mode -r)

hwti · « **Réponse #117 le:** 29 février 2016 à 17:33:43 »

Citation de: vivien le 29 février 2016 à 17:00:45

La durée c'est idéal, mais je n'ai pas trouvé comment faire... j'ai hésité en lançant un sleep en parallèle qui va killer le process

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

Code: [Sélectionner]

~ curl -4 -o /dev/null --max-time 5 --write-out "%{time_namelookup} %{time_connect} %{time_starttransfer} %{time_total} %{size_download}" http://1.testdebit.info/fichiers/5000Mo/5000Mo.jpg
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 4768M    0 20.2M    0     0  4976k      0  0:16:21  0:00:04  0:16:17 4975kcurl: (28) Operation timed out after 4999 milliseconds with 25501949 out of 5000000000 bytes received
0,004 0,010 0,016 4,999 25501949

kgersen · « **Réponse #118 le:** 29 février 2016 à 18:02:35 »

la todo list:

- plus de tailles ok. en fait je ne vais plus faire de contrôle de taille, y'aura une erreur si le serveur ne supporte pas cette taille. c'est plus simple pour moi qu'une liste de valeurs fixes. L'option -size 'parsera' donc X, XM, XG et XT, X étant un nombre entier strictement positif

- date et heure début/fin : ok. je comptais afficher l'OS et la version aussi.

- formatage résultats. des tabulations suffisent ou place fixe?

- extension de fichier. actuellement le script ne contrôle pas donc on met ce qu'on veut.

- un test sur la durée est prévu dans le serveur de debit en cours de réalisation (nspeed). mais je peux ajouter --max-time facilement en attendant si c'est consistent en terme de résultat.

- SQL par contre je ne vois pas l’intérêt ? je suis plutôt partisan de la philosophie Unix ou chaque commande/programme fait un seul truc mais bien et ensuite on les combien avec des pipes et/ou des scripts.
Je peux faire une option d'affichage en forme csv par exemple ou meme json qu'on peut ensuite "piper" dans un client sql ou uploader dans un logstash ou n'importe quoi d'autre (n'importe quel client sql cli peut lire un csv pour l'ajouter dans un BdD).

- i18n : j'ai rien prévu pour le moment, est-ce nécessaire pour ce genre de truc ?

pour Windows il est facile (il me semble) de générer un ficher .exe unique qui combien le script perl, curl et l’interpréteur perl (avec PAR:Packer). Si quelqu'un est expert la dedans qu'il se signale.

on va 'feature freeze' tout ca pour la v1. donc s'il manque des trucs c'est maintenant ou jamais.

hwti · « **Réponse #119 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).