"|dd if=/dev/zero bs=32k count=10000" /dev/null

2008-04-27, 01:02(+02), mpg:

Le (on) samedi 26 avril 2008 21:18, Stephane Chazelas a écrit (wrote) :

que veut dire escaper les espaces ?

"escaper", ca veut souvent dire retirer sa signification
speciale. Le " " dans les commandes ftp a une signification
speciale, celle de separer les mots.

Au passage, quelques traductions :

- en franglais, escaper ;
- en anglais, to escape ;
- en français, échapper.

Chacun choisit sa langue préférée :-)
[...]

Disons que "escape", je sais ce que ca veut dire, "echapper", je
ne devine que si je fais l'effort de d'abord traduire
litteralement vers l'Anglais, sinon ca ne me parle pas.

Je sais c'est triste, mais les documents qui parlent
d'informatique en Francais pedantique (surement un autre
franglisme) me sont bien plus penibles a lire que ceux en
Anglais ou ceux en Francais qui ne font pas l'effort de traduire
les termes techniques.

Typiquement, pour moi LC_MESSAGES=fr_FR, c'est du
LC_MESSAGES=he_IL ;)

--
Stéphane

2008-04-27, 10:06(+02), Thierry B.:

--{ Alain Montfranc a plopé ceci: }--

Donc, en gros, ca envoie 320000k par le reseau (ou moins, car dd
ne verifie pas si les blocks sont ecrits completement).

C'est assez nul en fait car 32000k de zeros ca se compresse aisément :
pour peu que le flux soit compressé ca change bcp de choses...

Remplacer /dev/zero par /dev/[u]random ?

Auquel cas, on ne fait que tester la performance (ou
non-randomitude) du pseudo-random generator.

$ dd count of=/dev/null if=/dev/random
0+10 records in
0+1 records out
91 bytes (91 B) copied, 26.6529 s, 0.0 kB/s

$ dd count000 of=/dev/null if=/dev/urandom
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 1.38272 s, 3.7 MB/s

$ dd count000 of=/dev/null if=/dev/zero
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.00695085 s, 737 MB/s


Typiquement, can on test un reseau, c'est un reseau local, ca
serait pas tres civique d'envoyer du /dev/zero sur internet,
auquel cas, il n'y aura en general pas de compression et de nos
jours on a des debits superieurs a 3.7 MB/s.

--
Stéphane

Stephane Chazelas a écrit

Typiquement, can on test un reseau, c'est un reseau local, ca

a ? a par perrrier vou aver dai soursses ?

serait pas tres civique d'envoyer du /dev/zero sur internet,
auquel cas, il n'y aura en general pas de compression et de nos
jours on a des debits superieurs a 3.7 MB/s.

2008-04-27, 15:32(+02), Alain Montfranc:

Stephane Chazelas a écrit

Typiquement, can on test un reseau, c'est un reseau local, ca

Je suis allé jusqu'a consulter mon folder "My_Posts" pour
verifier que j'avais bien ecrit ca ! Effrayant !

Je me console en constatant que "can" "on" et "test" sont
valides en Anglais (rapport a l'autre thread).

a ? a par perrrier vou aver dai soursses ?
[...]

Ben, sinon, on ne teste pas un reseau, on teste internet.

Bon, maintenant, va s'agir de rattrapper le sommeil de retard...
Ca a pas que du bon, la paternité... Surtout au niveau de
l'orthographe.

--
Stéphane

On 25 avr, 18:20, Stephane Chazelas <cette.adre...@est.invalid> wrote:

2008-04-25, 06:44(-07), scratt:

Bonjour,

Quelqu'un peut il me detailler la syntaxe de cette commande :
put "|dd if=/dev/zero bs=32k count=10000" /dev/null

Que j'ai trouvé dans un ftp pour mesurer le debit reseau .

ftp> put "|dd if=/dev/zero bs=32k count=10000" /dev/null
200 Commande PORT réussie.
150 Ouverture de la connexion de données pour /dev/null.
10000+0 enregistrements en entrée.
10000+0 enregistrements en sortie.
226 Transfert terminé.
327680000 octets envoyés en 1,867 secondes (1,714e+05 ko/s)
local : |dd if=/dev/zero bs=32k count=10000 distant : /dev/null
ftp>

ce qu je ne comprends pas c'est les doubles cotes et le pipe juste
avant dd.

[...]

C'est une convention de ton client ftp.

Normalement, put est utilisé comme:

put /path/to/local-file /path/to/remote-file

Avec un | devant le local-file, ca ne le traite plus comme un
fichier mais comme une commande a executer et c'est le
standard-output de la commande qui est envoyé a la place du
contenu du fichier.

Les "..." c'est pour escaper les espaces.

Donc, en gros, ca envoie 320000k par le reseau (ou moins, car dd
ne verifie pas si les blocks sont ecrits completement).

--
Stéphane

Vous dites et je vous croie puisque ca marche, que c'est une
convention de monclient FTP, pourtant quand je fais HELP dans mon
client ftp ca n'en parle aps !!!

On 27 avr, 11:02, Alain Montfranc <x...@x.con> wrote:

Thierry B. a écrit

--{ Alain Montfranc a plopé ceci: }--

Donc, en gros, ca envoie 320000k par le reseau (ou moins, car dd
ne verifie pas si les blocks sont ecrits completement).

C'est assez nul en fait car 32000k de zeros ca se compresse aisément :
pour peu que le flux soit compressé ca change bcp de choses...

Remplacer /dev/zero par /dev/[u]random ?

Qu'elle est la différence entre random et urandom ?

scratt wrote in message
<58b63ef6-2143-4552-baec-1ed4d356618f@27g2000hsf.googlegroups.com>:

Qu'elle est la différence entre random et urandom ?

/dev/random est alimenté uniquement par les sources d'aléa extérieures :
activité des interruptions, etc. L'OS garde une estimation de la quantité
d'aléa disponible. Quand on lit, cette quantité d'aléa est diminuée ; quand
elle arrive à 0, la lecture bloque jusqu'à ce que des sources d'aléa
extérieures alimentent le réservoir.

/dev/urandom est aussi alimenté par ces sources d'aléa extérieures, mais
lors des lectures, au lieu de considérer que cet aléa est consommé, l'OS le
brasse par des dispositifs arithmétiques.

Le résultat est qu'en théorie, la sortie d'urandom est prévisible après
quelques lectures et si l'activité extérieure est insuffisante, mais qu'en
pratique, la taille des réservoirs d'aléa mis en jeu est telle que c'est
totalement irréaliste. Les cryptographes s'accordent pour considérer
qu'urandom est suffisant pour tous les usages.

On 28 avr, 10:56, Nicolas George <nicolas$geo...@salle-s.org> wrote:

scratt wrote in message

<58b63ef6-2143-4552-baec-1ed4d3566...@27g2000hsf.googlegroups.com>:

Qu'elle est la différence entre random et urandom ?

/dev/random est alimenté uniquement par les sources d'aléa extérieur es :
activité des interruptions, etc. L'OS garde une estimation de la quantit é
d'aléa disponible. Quand on lit, cette quantité d'aléa est diminué e ; quand
elle arrive à 0, la lecture bloque jusqu'à ce que des sources d'aléa
extérieures alimentent le réservoir.

/dev/urandom est aussi alimenté par ces sources d'aléa extérieures, mais
lors des lectures, au lieu de considérer que cet aléa est consommé, l'OS le
brasse par des dispositifs arithmétiques.

Le résultat est qu'en théorie, la sortie d'urandom est prévisible ap rès
quelques lectures et si l'activité extérieure est insuffisante, mais q u'en
pratique, la taille des réservoirs d'aléa mis en jeu est telle que c'e st
totalement irréaliste. Les cryptographes s'accordent pour considérer
qu'urandom est suffisant pour tous les usages.

A quoi ca sert ? Quel est l'origine de l'utilité de ces devices ?

scratt wrote in message
<e0704e47-b846-4dd6-9a4a-e63334654525@d1g2000hsg.googlegroups.com>:

A quoi ca sert ? Quel est l'origine de l'utilité de ces devices ?

Ça sert à tirer des nombres au hasard. Un ordinateur est un dispositif
normalement totalement déterministe : si on a besoin de données aléatoires
(pour générer une clef de chiffrement, typiquement, ou pour des simulations
(ou des jeux)), il faut aller les chercher dans une source extérieure. Les
sources usuellement utilisées, comme l'heure à laquelle le programme est
lancé, sont acceptables pour des petits jeux, et même souvent pour des
simulations. Mais pour de la cryptographie, elles sont trop prévisibles.

Nicolas George <nicolas$george@salle-s.org> wrote:

Non, c'est /dev/zemo la source infinie de zémos.

Des zémos qui se resemblent comme deux goutes d'ho ! ;-)

--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas