La Fibre
Télécom => Réseau => 
Comment tester son débit ? => Discussion démarrée par: vivien le 16 octobre 2012 à 19:02:59
-
Comment créer des fichiers arbitrairement lourds pour tester son débit ?
/dev/random est un fichier spécial qui sert de générateur de nombres aléatoires.
/dev/urandom est plus rapide, mais l'aléa produit est donc de moins bonne qualité.
/dev/zero ne contient que des zéros.
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
Pour un fichier de 1024 octets :
dd if=/dev/urandom of=./1Kio.dat bs=2b count=1
1+0 enregistrements lus
1+0 enregistrements écrits
1024 octets (1,0 kB) copiés, 0,000275317 s, 3,7 MB/s
-
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
Fais comme moi, Vivien : dis stop au gaspillage de ressources et au temps inutilement perdu !
Pourquoi se fatiguer à écrire 100 000 blocs de 1K de vide ...
$ time dd if=/dev/zero of=/tmp/100Mo.fic1 bs=1K count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
102400000 octets (102 MB) copiés, 1,84205 s, 55,6 MB/s
real 0m1.853s
user 0m0.212s
sys 0m1.640s
... quand il suffit de se déplacer de 99 999 blocs et d'en écrire un seul ...
$ time dd if=/dev/zero of=/tmp/100Mo.fic2 bs=1K seek=99999 count=1
1+0 enregistrements lus
1+0 enregistrements écrits
1024 octets (1,0 kB) copiés, 0,000105352 s, 9,7 MB/s
real 0m0.011s
user 0m0.000s
sys 0m0.008s
... pour aboutir au même résultat ?
$ ls -l /tmp/100Mo.fic*
-rw-r--r-- 1 Sebastien Sebastien 102400000 16 oct. 19:56 /tmp/100Mo.fic1
-rw-r--r-- 1 Sebastien Sebastien 102400000 16 oct. 19:57 /tmp/100Mo.fic2
Avec cette technique, tu peux te créer un fichier vide de 1 To en un battement de cil :
$ time dd if=/dev/zero of=/tmp/1To.fic bs=1K seek=99999999 count=1
1+0 enregistrements lus
1+0 enregistrements écrits
1024 octets (1,0 kB) copiés, 0,000109556 s, 9,3 MB/s
real 0m0.011s
user 0m0.000s
sys 0m0.012s
$ ls -l /tmp/1To.fic
-rw-r--r-- 1 Sebastien Sebastien 102400000000 16 oct. 20:13 /tmp/1To.fic
Je suis sûr que tu vas adorer ! ;)
-
Je vais l'utiliser pour générer les fichiers de https://testdebit.info/ (https://testdebit.info/)
Je pense proposer les tailles suivantes (générées en random et zerro afin de voir l'impact d'une compression) :
1Mo.rand
2Mo.rand
5Mo.rand
10Mo.rand
20Mo.rand
50Mo.rand
100Mo.rand
200Mo.rand
500Mo.rand
1000Mo.rand
1000Mo-1.rand
1000Mo-2.rand
1000Mo-3.rand
1000Mo-4.rand
1000Mo-5.rand
1000Mo-6.rand
1000Mo-7.rand
1000Mo-8.rand
1000Mo-9.rand
1Mo.zero
5Mo.zero
20Mo.zero
100Mo.zero
500Mo.zero
1Mo.txt
5Mo.txt
20Mo.txt
1Mo.jpg
5Mo.jpg
20Mo.jpg
5Mo.png (http://1.testdebit.info/fichiers/5Mo.png) (je me suis cassé la tête pour que ces photos fassent exactement 5 Mo et 20 Mo au bit prés)
20Mo.png (http://1.testdebit.info/fichiers/20Mo.png)
Total :
- 1888 Mo pour les fichiers RAND (les fichiers 1000Mo-1.rand et suivants sont des liens de 1000Mo.rand)
- 626 Mo pour les fichiers .zero
- 26 Mo pour les fichiers .txt
- 26 Mo pour les fichiers .jpg
- 25 Mo pour les fichiers .png
Total : 2591 Mo
=> Un serveur avec 4 Go de RAM peux avoir ces fichiers en RAM ce qui permet d'avoir de très bonnes performances.
-
Intéressante cette technique. C'est donc le bit 1 qui définit la fin d'un fichier??
-
Le bit 1 de quoi donc ? ???
La taille d'un fichier est définie par la différence entre la position 0 et celle de son dernier octet de données.
C'est pour ça qu'en avançant dans le fichier de n-1 ko et en écrivant 1 ko, le fichier fait au final n ko.
Ceci étant dit, le système de fichiers n'est pas dupe de ce petit manège.
Si je crée un fichier contenant 16 Ko de données ...
$ dd if=/dev/urandom of=/tmp/random bs=1K count=16
16+0 enregistrements lus
16+0 enregistrements écrits
16384 octets (16 kB) copiés, 0,00830498 s, 2,0 MB/s
... il fait bien 16 ko, et on voit que 32 blocs de 512 octets (soit 16 ko) lui ont bien été alloués :
$ stat /tmp/random
File: « /tmp/random »
Size: 16384 Blocks: 32 IO Block: 4096 fichier
Device: fd00h/64768d Inode: 391983 Links: 1
(...)
Si je supprime maintenant le fichier pour invalider son i-nœud, et que je recommence l'opération en n'écrivant effectivement qu'un seul ko de données ...
$ rm /tmp/random
$ dd if=/dev/urandom of=/tmp/random bs=1K seek=15 count=1
1+0 enregistrements lus
1+0 enregistrements écrits
1024 octets (1,0 kB) copiés, 0,000592388 s, 1,7 MB/s
... il fait toujours 16 ko, mais seuls 8 blocs de 512 octets (soit 4 ko = la taille minimale d'un bloc d'E/S) lui ont effectivement été alloués :
$ stat /tmp/random
File: « /tmp/random »
Size: 16384 Blocks: 8 IO Block: 4096 fichier
Device: fd00h/64768d Inode: 391983 Links: 1
(...)
Ce qui dans l'absolu ne change rien, puisque si je demande à lire le fichier, l'OS va me retourner 15 359 zéros avant de me donner à lire le dernier ko de données utiles :
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00003c00 30 ff ea 85 e0 e4 94 c2 22 ae fa a8 8c 8d 04 35 |0......."......5|
(...)
00003ff0 a5 ab 9c 1d 3d 5a 4c 13 8b cb 1d ac 4e 67 4c 55 |....=ZL.....NgLU|
00004000
Mais bon, c'est un cas un peu tordu.
Du fait de la taille minimale d'un bloc d'E/S, un fichier occupe généralement plus d'espace disque que sa taille effective (ou logique).
-
Je vais l'utiliser pour générer les fichiers de https://testdebit.info/ (https://testdebit.info/)
C'est en ligne !
J'ai rajouté des images .jpg de exactement 1Mo (http://1.testdebit.info/fichiers/1Mo.jpg), 5Mo (http://1.testdebit.info/fichiers/5Mo.jpg), 20Mo (http://1.testdebit.info/fichiers/20Mo.jpg). Ma méthode : j'ai coupé un fichier .jpeg avant la fin (c'est un peu barbare)
Pour les images 5Mo.png (http://1.testdebit.info/fichiers/5Mo.png) et 20Mo.png (http://1.testdebit.info/fichiers/20Mo.png), j'ai ajusté pixel par pixel avec une zone transparente en bas à droite qui prend moins de place que la photo pour avoir pille poil la taille.
Pour info, voici la ligne de commande utilisée pour créer les lien physiques : ln 1000Mo.dat 1000Mo-1.dat ; ln 1000Mo.dat 1000Mo-2.dat ; ln 1000Mo.dat 1000Mo-3.dat ; ln 1000Mo.dat 1000Mo-4.dat ; ln 1000Mo.dat 1000Mo-5.dat ; ln 1000Mo.dat 1000Mo-6.dat ; ln 1000Mo.dat 1000Mo-7.dat ; ln 1000Mo.dat 1000Mo-8.dat ; ln 1000Mo.dat 1000Mo-9.dat
Le but d'avoir plusieurs type de fichier est de tester le problématiques du type Free Mobile briderait la vitesse de téléchargement sur les fichiers multimédia (https://lafibre.info/free-mobile/free-mobile-briderait-la-vitesse/)