Bonjour,
j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquelles je vais
copier les mêmes données (env 50M). Comme je vais devoir faire cela pour un
grand nombre de clés, j'ai écrit un script shell qui m'automatise tout ça. En
gros, il fait
for i in a b c d e f
do
monte la clé $i
copie les fichiers
done.
Ce qui est surprenant et qui fait que je m'adresse à vous, c'est que les temps
de copies augmentent avec le rang de la clé :
Quelle est la cause de ce phénomène ? Comment le corriger afin d'optimiser le
processus ? Est-ce en rapport avec le montage des périphériques ? le noyau ?
Bonjour,
j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquelles je vais
copier les mêmes données (env 50M). Comme je vais devoir faire cela pour un
grand nombre de clés, j'ai écrit un script shell qui m'automatise tout ça. En
gros, il fait
for i in a b c d e f
do
monte la clé $i
copie les fichiers
done.
Ce qui est surprenant et qui fait que je m'adresse à vous, c'est que les temps
de copies augmentent avec le rang de la clé :
Quelle est la cause de ce phénomène ? Comment le corriger afin d'optimiser le
processus ? Est-ce en rapport avec le montage des périphériques ? le noyau ?
Bonjour,
j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquelles je vais
copier les mêmes données (env 50M). Comme je vais devoir faire cela pour un
grand nombre de clés, j'ai écrit un script shell qui m'automatise tout ça. En
gros, il fait
for i in a b c d e f
do
monte la clé $i
copie les fichiers
done.
Ce qui est surprenant et qui fait que je m'adresse à vous, c'est que les temps
de copies augmentent avec le rang de la clé :
Quelle est la cause de ce phénomène ? Comment le corriger afin d'optimiser le
processus ? Est-ce en rapport avec le montage des périphériques ? le noyau ?
* steve [2006-03-16 16:29] :
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquel les je
> vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> pour un grand nombre de clés, j'ai écrit un script shell qui m'auto matise
> tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
> done.
>
> Ce qui est surprenant et qui fait que je m'adresse à vous, c'est que les
> temps de copies augmentent avec le rang de la clé :
[...]
> Quelle est la cause de ce phénomène ? Comment le corriger afin
> d'optimiser le processus ? Est-ce en rapport avec le montage des
> périphériques ? le noyau ?
Cela peut venir des clés elles-même (les clés USB peuvent avoir des
vitesses variables selon leur qualité¹)
, du pilote USB
ou encore de la
norme USB (il est peut-être possible que le débit soit partagé selo n le
nombre de périphériques montés²).
Est-ce qu'en changeant l'ordre des clés tu as le même comportement ?
Est-ce qu'en démontant les clés dans la boucle juste après la copie des
données les résultats sont meilleurs ?
Est-ce que tes clés sont montés en synchrone ou asynchrone (mode par
défaut) ?
Fred
¹ cela paraît cependant assez étonnant d'avoir une telle régulari té
² je n'ai rien trouvé dans la page http://en.wikipedia.org/wiki/USB q ui
pourrait confirmer cela
--
Comment poser les questions de manière intelligente ?
http://www.gnurou.org/Writing/SmartQuestionsFr
Comment signaler efficacement un bug ?
http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
* steve <dlist@bluewin.ch> [2006-03-16 16:29] :
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquel les je
> vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> pour un grand nombre de clés, j'ai écrit un script shell qui m'auto matise
> tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
> done.
>
> Ce qui est surprenant et qui fait que je m'adresse à vous, c'est que les
> temps de copies augmentent avec le rang de la clé :
[...]
> Quelle est la cause de ce phénomène ? Comment le corriger afin
> d'optimiser le processus ? Est-ce en rapport avec le montage des
> périphériques ? le noyau ?
Cela peut venir des clés elles-même (les clés USB peuvent avoir des
vitesses variables selon leur qualité¹)
, du pilote USB
ou encore de la
norme USB (il est peut-être possible que le débit soit partagé selo n le
nombre de périphériques montés²).
Est-ce qu'en changeant l'ordre des clés tu as le même comportement ?
Est-ce qu'en démontant les clés dans la boucle juste après la copie des
données les résultats sont meilleurs ?
Est-ce que tes clés sont montés en synchrone ou asynchrone (mode par
défaut) ?
Fred
¹ cela paraît cependant assez étonnant d'avoir une telle régulari té
² je n'ai rien trouvé dans la page http://en.wikipedia.org/wiki/USB q ui
pourrait confirmer cela
--
Comment poser les questions de manière intelligente ?
http://www.gnurou.org/Writing/SmartQuestionsFr
Comment signaler efficacement un bug ?
http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
* steve [2006-03-16 16:29] :
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquel les je
> vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> pour un grand nombre de clés, j'ai écrit un script shell qui m'auto matise
> tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
> done.
>
> Ce qui est surprenant et qui fait que je m'adresse à vous, c'est que les
> temps de copies augmentent avec le rang de la clé :
[...]
> Quelle est la cause de ce phénomène ? Comment le corriger afin
> d'optimiser le processus ? Est-ce en rapport avec le montage des
> périphériques ? le noyau ?
Cela peut venir des clés elles-même (les clés USB peuvent avoir des
vitesses variables selon leur qualité¹)
, du pilote USB
ou encore de la
norme USB (il est peut-être possible que le débit soit partagé selo n le
nombre de périphériques montés²).
Est-ce qu'en changeant l'ordre des clés tu as le même comportement ?
Est-ce qu'en démontant les clés dans la boucle juste après la copie des
données les résultats sont meilleurs ?
Est-ce que tes clés sont montés en synchrone ou asynchrone (mode par
défaut) ?
Fred
¹ cela paraît cependant assez étonnant d'avoir une telle régulari té
² je n'ai rien trouvé dans la page http://en.wikipedia.org/wiki/USB q ui
pourrait confirmer cela
--
Comment poser les questions de manière intelligente ?
http://www.gnurou.org/Writing/SmartQuestionsFr
Comment signaler efficacement un bug ?
http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
steve a écrit :
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquel les je
> vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> pour un grand nombre de clés, j'ai écrit un script shell qui m'auto matise
> tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
peut-être démonter la clé $i ??
--
Fred.
steve <dlist@bluewin.ch> a écrit :
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquel les je
> vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> pour un grand nombre de clés, j'ai écrit un script shell qui m'auto matise
> tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
peut-être démonter la clé $i ??
--
Fred.
steve a écrit :
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquel les je
> vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> pour un grand nombre de clés, j'ai écrit un script shell qui m'auto matise
> tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
peut-être démonter la clé $i ??
--
Fred.
Le Jeudi, 16 Mars 2006 17.52, Frédéric Bothamy a écrit :
> * steve [2006-03-16 16:29] :
> > Bonjour,
> >
> > j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquelles je
> > vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> > pour un grand nombre de clés, j'ai écrit un script shell qui m'automatise
> > tout ça. En gros, il fait
> >
> > for i in a b c d e f
> > do
> > monte la clé $i
> > copie les fichiers
> > done.
> >
> > Ce qui est surprenant et qui fait que je m'adresse à vous, c'est que les
> > temps de copies augmentent avec le rang de la clé :
>
> [...]
>
> > Quelle est la cause de ce phénomène ? Comment le corriger afin
> > d'optimiser le processus ? Est-ce en rapport avec le montage des
> > périphériques ? le noyau ?
>
> Cela peut venir des clés elles-même (les clés USB peuvent avoir des
> vitesses variables selon leur qualité¹)
c'est un lot (2400 quand même !) de clé, toutes pareilles.
> , du pilote USB
ça c'est le noyau..?
> ou encore de la
> norme USB (il est peut-être possible que le débit soit partagé selon le
> nombre de périphériques montés²).
c'est possible : le hub du usb 2 alors que mon port est du 1.0. je vais faire
des tests en usb 2.
> Est-ce qu'en changeant l'ordre des clés tu as le même comportement ?
1ère permutation : 3 tests
4, 3, 15, 21, 31, 38
3, 2, 4, 36, 44, 32
2, 2, 5, 38, 21, 58
2ème permutations : 3 tests
2, 2, 4, 32, 47, 14
3, 2, 6, 31, 46, 29
2, 2, 5, 36, 32, 39
etc..
bon apparemment, il y a un saut à la 4ème clé puis ça se calme.
>
> Est-ce qu'en démontant les clés dans la boucle juste après la copie des
> données les résultats sont meilleurs ?
non; d'après mes tests, il est plus rapide de tout démonter après la boucle
qu'à la fin de la copie. vas comprendre.
> Est-ce que tes clés sont montés en synchrone ou asynchrone (mode par
> défaut) ?
comme je ne sais pas ce que c'est, ça doit être en asynchrone. D'ailleurs
comment tu fais pour passer en synchrone ? peut-être est-ce plus rapide ?
Le Jeudi, 16 Mars 2006 17.52, Frédéric Bothamy a écrit :
> * steve <dlist@bluewin.ch> [2006-03-16 16:29] :
> > Bonjour,
> >
> > j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquelles je
> > vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> > pour un grand nombre de clés, j'ai écrit un script shell qui m'automatise
> > tout ça. En gros, il fait
> >
> > for i in a b c d e f
> > do
> > monte la clé $i
> > copie les fichiers
> > done.
> >
> > Ce qui est surprenant et qui fait que je m'adresse à vous, c'est que les
> > temps de copies augmentent avec le rang de la clé :
>
> [...]
>
> > Quelle est la cause de ce phénomène ? Comment le corriger afin
> > d'optimiser le processus ? Est-ce en rapport avec le montage des
> > périphériques ? le noyau ?
>
> Cela peut venir des clés elles-même (les clés USB peuvent avoir des
> vitesses variables selon leur qualité¹)
c'est un lot (2400 quand même !) de clé, toutes pareilles.
> , du pilote USB
ça c'est le noyau..?
> ou encore de la
> norme USB (il est peut-être possible que le débit soit partagé selon le
> nombre de périphériques montés²).
c'est possible : le hub du usb 2 alors que mon port est du 1.0. je vais faire
des tests en usb 2.
> Est-ce qu'en changeant l'ordre des clés tu as le même comportement ?
1ère permutation : 3 tests
4, 3, 15, 21, 31, 38
3, 2, 4, 36, 44, 32
2, 2, 5, 38, 21, 58
2ème permutations : 3 tests
2, 2, 4, 32, 47, 14
3, 2, 6, 31, 46, 29
2, 2, 5, 36, 32, 39
etc..
bon apparemment, il y a un saut à la 4ème clé puis ça se calme.
>
> Est-ce qu'en démontant les clés dans la boucle juste après la copie des
> données les résultats sont meilleurs ?
non; d'après mes tests, il est plus rapide de tout démonter après la boucle
qu'à la fin de la copie. vas comprendre.
> Est-ce que tes clés sont montés en synchrone ou asynchrone (mode par
> défaut) ?
comme je ne sais pas ce que c'est, ça doit être en asynchrone. D'ailleurs
comment tu fais pour passer en synchrone ? peut-être est-ce plus rapide ?
Le Jeudi, 16 Mars 2006 17.52, Frédéric Bothamy a écrit :
> * steve [2006-03-16 16:29] :
> > Bonjour,
> >
> > j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquelles je
> > vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> > pour un grand nombre de clés, j'ai écrit un script shell qui m'automatise
> > tout ça. En gros, il fait
> >
> > for i in a b c d e f
> > do
> > monte la clé $i
> > copie les fichiers
> > done.
> >
> > Ce qui est surprenant et qui fait que je m'adresse à vous, c'est que les
> > temps de copies augmentent avec le rang de la clé :
>
> [...]
>
> > Quelle est la cause de ce phénomène ? Comment le corriger afin
> > d'optimiser le processus ? Est-ce en rapport avec le montage des
> > périphériques ? le noyau ?
>
> Cela peut venir des clés elles-même (les clés USB peuvent avoir des
> vitesses variables selon leur qualité¹)
c'est un lot (2400 quand même !) de clé, toutes pareilles.
> , du pilote USB
ça c'est le noyau..?
> ou encore de la
> norme USB (il est peut-être possible que le débit soit partagé selon le
> nombre de périphériques montés²).
c'est possible : le hub du usb 2 alors que mon port est du 1.0. je vais faire
des tests en usb 2.
> Est-ce qu'en changeant l'ordre des clés tu as le même comportement ?
1ère permutation : 3 tests
4, 3, 15, 21, 31, 38
3, 2, 4, 36, 44, 32
2, 2, 5, 38, 21, 58
2ème permutations : 3 tests
2, 2, 4, 32, 47, 14
3, 2, 6, 31, 46, 29
2, 2, 5, 36, 32, 39
etc..
bon apparemment, il y a un saut à la 4ème clé puis ça se calme.
>
> Est-ce qu'en démontant les clés dans la boucle juste après la copie des
> données les résultats sont meilleurs ?
non; d'après mes tests, il est plus rapide de tout démonter après la boucle
qu'à la fin de la copie. vas comprendre.
> Est-ce que tes clés sont montés en synchrone ou asynchrone (mode par
> défaut) ?
comme je ne sais pas ce que c'est, ça doit être en asynchrone. D'ailleurs
comment tu fais pour passer en synchrone ? peut-être est-ce plus rapide ?
Bonjour,
j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur
lesquelles je vais copier les mêmes données (env 50M). Comme je
vais devoir faire cela pour un grand nombre de clés, j'ai écrit un
script shell qui m'automatise tout ça. En gros, il fait
for i in a b c d e f
do
monte la clé $i
copie les fichiers
done.
Bonjour,
j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur
lesquelles je vais copier les mêmes données (env 50M). Comme je
vais devoir faire cela pour un grand nombre de clés, j'ai écrit un
script shell qui m'automatise tout ça. En gros, il fait
for i in a b c d e f
do
monte la clé $i
copie les fichiers
done.
Bonjour,
j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur
lesquelles je vais copier les mêmes données (env 50M). Comme je
vais devoir faire cela pour un grand nombre de clés, j'ai écrit un
script shell qui m'automatise tout ça. En gros, il fait
for i in a b c d e f
do
monte la clé $i
copie les fichiers
done.
> > , du pilote USB
>
> ça c'est le noyau..?
Oui. À propos, tu utilises quel noyau ? (perso, j'ai déjà eu quelqu es
petits problèmes avec l'USB sur les noyaux 2.6.8-2.6.11).
> > ou encore de la
> > norme USB (il est peut-être possible que le débit soit partagé selon le
> > nombre de périphériques montés²).
>
> c'est possible : le hub du usb 2 alors que mon port est du 1.0. je vais
> faire des tests en usb 2.
>
> > Est-ce qu'en changeant l'ordre des clés tu as le même comportemen t ?
>
> 1ère permutation : 3 tests
>
> 4, 3, 15, 21, 31, 38
> 3, 2, 4, 36, 44, 32
> 2, 2, 5, 38, 21, 58
>
> 2ème permutations : 3 tests
>
> 2, 2, 4, 32, 47, 14
> 3, 2, 6, 31, 46, 29
> 2, 2, 5, 36, 32, 39
>
>
> etc..
>
> bon apparemment, il y a un saut à la 4ème clé puis ça se calme.
C'est tout de même assez préoccupant. Mais je crois que l'explication
se trouve ci-dessous.
> > Est-ce qu'en démontant les clés dans la boucle juste après la c opie des
> > données les résultats sont meilleurs ?
>
> non; d'après mes tests, il est plus rapide de tout démonter après la
> boucle qu'à la fin de la copie. vas comprendre.
En fait, ceci est incorrect : comme le noyau doit de toute façon copier
les fichiers vers les clés (et que c'est cela qui prend du temps), le
temps utilisé pour démonter les clés sert en fait à forcer la
synchronisation des fichiers et donc l'écriture des fichiers.
Ce temps
est incompressible (il peut avoir lieu lors du démontage de chaque clé
dans la boucle ou lors du démontage de toutes les clés à la fin).
> > Est-ce que tes clés sont montés en synchrone ou asynchrone (mode par
> > défaut) ?
>
> comme je ne sais pas ce que c'est, ça doit être en asynchrone. D'ai lleurs
> comment tu fais pour passer en synchrone ? peut-être est-ce plus rapi de ?
Il suffit d'ajouter sync dans la ligne du fichier /etc/fstab dans les
options (ou d'ajouter "-o sync" dans la commande mount).
En fait, ce qui se passe, c'est que le noyau met en cache les fichiers à
copier sur une clé, le comportement observé est alors me semble assez
logique : il ne déclenche la copie que quand il est obligé de le faire
(soit lors de la copie en mode synchrone, soit quand le noyau a besoin
de ressources ou quand tu démontes les clés en mode asynchrone).
Note : 2s pour copier 50 Mo sur une clé en USB 1, ce n'est pas réalis te.
:-)
D'après http://en.wikipedia.org/wiki/USB, en Full speed, tu peux
avoir du 1,4 Mo/s, la durée normale devrait donc être environ 35 s, s oit
la durée observée à partir de la 4e clé (à peu près).
Donc, au final, le comportement observé me semble normal bien
qu'étonnant à première vue.
Après, tu peux comparer ce qui est le plus
rapide entre les modes synchrone et asynchrone, je pense que la
différence ne sera pas énorme avec un petit avantage pour le mode
asynchrone (qui peut commencer la mise à jour de la première clé pe ndant
la mise en cache des fichiers des autres clés).
Un problème très intéressant et inhabituel...
Fred
--
Comment poser les questions de manière intelligente ?
http://www.gnurou.org/Writing/SmartQuestionsFr
Comment signaler efficacement un bug ?
http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
> > , du pilote USB
>
> ça c'est le noyau..?
Oui. À propos, tu utilises quel noyau ? (perso, j'ai déjà eu quelqu es
petits problèmes avec l'USB sur les noyaux 2.6.8-2.6.11).
> > ou encore de la
> > norme USB (il est peut-être possible que le débit soit partagé selon le
> > nombre de périphériques montés²).
>
> c'est possible : le hub du usb 2 alors que mon port est du 1.0. je vais
> faire des tests en usb 2.
>
> > Est-ce qu'en changeant l'ordre des clés tu as le même comportemen t ?
>
> 1ère permutation : 3 tests
>
> 4, 3, 15, 21, 31, 38
> 3, 2, 4, 36, 44, 32
> 2, 2, 5, 38, 21, 58
>
> 2ème permutations : 3 tests
>
> 2, 2, 4, 32, 47, 14
> 3, 2, 6, 31, 46, 29
> 2, 2, 5, 36, 32, 39
>
>
> etc..
>
> bon apparemment, il y a un saut à la 4ème clé puis ça se calme.
C'est tout de même assez préoccupant. Mais je crois que l'explication
se trouve ci-dessous.
> > Est-ce qu'en démontant les clés dans la boucle juste après la c opie des
> > données les résultats sont meilleurs ?
>
> non; d'après mes tests, il est plus rapide de tout démonter après la
> boucle qu'à la fin de la copie. vas comprendre.
En fait, ceci est incorrect : comme le noyau doit de toute façon copier
les fichiers vers les clés (et que c'est cela qui prend du temps), le
temps utilisé pour démonter les clés sert en fait à forcer la
synchronisation des fichiers et donc l'écriture des fichiers.
Ce temps
est incompressible (il peut avoir lieu lors du démontage de chaque clé
dans la boucle ou lors du démontage de toutes les clés à la fin).
> > Est-ce que tes clés sont montés en synchrone ou asynchrone (mode par
> > défaut) ?
>
> comme je ne sais pas ce que c'est, ça doit être en asynchrone. D'ai lleurs
> comment tu fais pour passer en synchrone ? peut-être est-ce plus rapi de ?
Il suffit d'ajouter sync dans la ligne du fichier /etc/fstab dans les
options (ou d'ajouter "-o sync" dans la commande mount).
En fait, ce qui se passe, c'est que le noyau met en cache les fichiers à
copier sur une clé, le comportement observé est alors me semble assez
logique : il ne déclenche la copie que quand il est obligé de le faire
(soit lors de la copie en mode synchrone, soit quand le noyau a besoin
de ressources ou quand tu démontes les clés en mode asynchrone).
Note : 2s pour copier 50 Mo sur une clé en USB 1, ce n'est pas réalis te.
:-)
D'après http://en.wikipedia.org/wiki/USB, en Full speed, tu peux
avoir du 1,4 Mo/s, la durée normale devrait donc être environ 35 s, s oit
la durée observée à partir de la 4e clé (à peu près).
Donc, au final, le comportement observé me semble normal bien
qu'étonnant à première vue.
Après, tu peux comparer ce qui est le plus
rapide entre les modes synchrone et asynchrone, je pense que la
différence ne sera pas énorme avec un petit avantage pour le mode
asynchrone (qui peut commencer la mise à jour de la première clé pe ndant
la mise en cache des fichiers des autres clés).
Un problème très intéressant et inhabituel...
Fred
--
Comment poser les questions de manière intelligente ?
http://www.gnurou.org/Writing/SmartQuestionsFr
Comment signaler efficacement un bug ?
http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
> > , du pilote USB
>
> ça c'est le noyau..?
Oui. À propos, tu utilises quel noyau ? (perso, j'ai déjà eu quelqu es
petits problèmes avec l'USB sur les noyaux 2.6.8-2.6.11).
> > ou encore de la
> > norme USB (il est peut-être possible que le débit soit partagé selon le
> > nombre de périphériques montés²).
>
> c'est possible : le hub du usb 2 alors que mon port est du 1.0. je vais
> faire des tests en usb 2.
>
> > Est-ce qu'en changeant l'ordre des clés tu as le même comportemen t ?
>
> 1ère permutation : 3 tests
>
> 4, 3, 15, 21, 31, 38
> 3, 2, 4, 36, 44, 32
> 2, 2, 5, 38, 21, 58
>
> 2ème permutations : 3 tests
>
> 2, 2, 4, 32, 47, 14
> 3, 2, 6, 31, 46, 29
> 2, 2, 5, 36, 32, 39
>
>
> etc..
>
> bon apparemment, il y a un saut à la 4ème clé puis ça se calme.
C'est tout de même assez préoccupant. Mais je crois que l'explication
se trouve ci-dessous.
> > Est-ce qu'en démontant les clés dans la boucle juste après la c opie des
> > données les résultats sont meilleurs ?
>
> non; d'après mes tests, il est plus rapide de tout démonter après la
> boucle qu'à la fin de la copie. vas comprendre.
En fait, ceci est incorrect : comme le noyau doit de toute façon copier
les fichiers vers les clés (et que c'est cela qui prend du temps), le
temps utilisé pour démonter les clés sert en fait à forcer la
synchronisation des fichiers et donc l'écriture des fichiers.
Ce temps
est incompressible (il peut avoir lieu lors du démontage de chaque clé
dans la boucle ou lors du démontage de toutes les clés à la fin).
> > Est-ce que tes clés sont montés en synchrone ou asynchrone (mode par
> > défaut) ?
>
> comme je ne sais pas ce que c'est, ça doit être en asynchrone. D'ai lleurs
> comment tu fais pour passer en synchrone ? peut-être est-ce plus rapi de ?
Il suffit d'ajouter sync dans la ligne du fichier /etc/fstab dans les
options (ou d'ajouter "-o sync" dans la commande mount).
En fait, ce qui se passe, c'est que le noyau met en cache les fichiers à
copier sur une clé, le comportement observé est alors me semble assez
logique : il ne déclenche la copie que quand il est obligé de le faire
(soit lors de la copie en mode synchrone, soit quand le noyau a besoin
de ressources ou quand tu démontes les clés en mode asynchrone).
Note : 2s pour copier 50 Mo sur une clé en USB 1, ce n'est pas réalis te.
:-)
D'après http://en.wikipedia.org/wiki/USB, en Full speed, tu peux
avoir du 1,4 Mo/s, la durée normale devrait donc être environ 35 s, s oit
la durée observée à partir de la 4e clé (à peu près).
Donc, au final, le comportement observé me semble normal bien
qu'étonnant à première vue.
Après, tu peux comparer ce qui est le plus
rapide entre les modes synchrone et asynchrone, je pense que la
différence ne sera pas énorme avec un petit avantage pour le mode
asynchrone (qui peut commencer la mise à jour de la première clé pe ndant
la mise en cache des fichiers des autres clés).
Un problème très intéressant et inhabituel...
Fred
--
Comment poser les questions de manière intelligente ?
http://www.gnurou.org/Writing/SmartQuestionsFr
Comment signaler efficacement un bug ?
http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
Le Thu, 16 Mar 2006 16:29:28 +0100
steve a écrit:
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur
> lesquelles je vais copier les mêmes données (env 50M). Comme je
> vais devoir faire cela pour un grand nombre de clés, j'ai écr it un
> script shell qui m'automatise tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
> done.
Et si tu fais dans l'autre sens (f->a) est-ce que ça fait pareil ou est-ce
que le temps le plus court est toujours sur sda?
Gaëtan
Le Thu, 16 Mar 2006 16:29:28 +0100
steve <dlist@bluewin.ch> a écrit:
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur
> lesquelles je vais copier les mêmes données (env 50M). Comme je
> vais devoir faire cela pour un grand nombre de clés, j'ai écr it un
> script shell qui m'automatise tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
> done.
Et si tu fais dans l'autre sens (f->a) est-ce que ça fait pareil ou est-ce
que le temps le plus court est toujours sur sda?
Gaëtan
Le Thu, 16 Mar 2006 16:29:28 +0100
steve a écrit:
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur
> lesquelles je vais copier les mêmes données (env 50M). Comme je
> vais devoir faire cela pour un grand nombre de clés, j'ai écr it un
> script shell qui m'automatise tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
> done.
Et si tu fais dans l'autre sens (f->a) est-ce que ça fait pareil ou est-ce
que le temps le plus court est toujours sur sda?
Gaëtan
> Ce temps
> est incompressible (il peut avoir lieu lors du démontage de chaque clé
> dans la boucle ou lors du démontage de toutes les clés à la fin).
ok, car si j'attends un moment avant de démonter les clés, le démontage est
quasi-instantané.
> En fait, ce qui se passe, c'est que le noyau met en cache les fichiers à
> copier sur une clé, le comportement observé est alors me semble assez
> logique : il ne déclenche la copie que quand il est obligé de le faire
> (soit lors de la copie en mode synchrone, soit quand le noyau a besoin
> de ressources ou quand tu démontes les clés en mode asynchrone).
Pourquoi ne le fait-il pas quand je le lui demande ? pourquoi est-ce que quand
la commande cp a terminé, les fichiers ne sont pas *vraiment* copiés ?
> Ce temps
> est incompressible (il peut avoir lieu lors du démontage de chaque clé
> dans la boucle ou lors du démontage de toutes les clés à la fin).
ok, car si j'attends un moment avant de démonter les clés, le démontage est
quasi-instantané.
> En fait, ce qui se passe, c'est que le noyau met en cache les fichiers à
> copier sur une clé, le comportement observé est alors me semble assez
> logique : il ne déclenche la copie que quand il est obligé de le faire
> (soit lors de la copie en mode synchrone, soit quand le noyau a besoin
> de ressources ou quand tu démontes les clés en mode asynchrone).
Pourquoi ne le fait-il pas quand je le lui demande ? pourquoi est-ce que quand
la commande cp a terminé, les fichiers ne sont pas *vraiment* copiés ?
> Ce temps
> est incompressible (il peut avoir lieu lors du démontage de chaque clé
> dans la boucle ou lors du démontage de toutes les clés à la fin).
ok, car si j'attends un moment avant de démonter les clés, le démontage est
quasi-instantané.
> En fait, ce qui se passe, c'est que le noyau met en cache les fichiers à
> copier sur une clé, le comportement observé est alors me semble assez
> logique : il ne déclenche la copie que quand il est obligé de le faire
> (soit lors de la copie en mode synchrone, soit quand le noyau a besoin
> de ressources ou quand tu démontes les clés en mode asynchrone).
Pourquoi ne le fait-il pas quand je le lui demande ? pourquoi est-ce que quand
la commande cp a terminé, les fichiers ne sont pas *vraiment* copiés ?
steve a écrit :
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquel les je
> vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> pour un grand nombre de clés, j'ai écrit un script shell qui m'auto matise
> tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
peut-être démonter la clé $i ??
--
Fred.
steve <dlist@bluewin.ch> a écrit :
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquel les je
> vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> pour un grand nombre de clés, j'ai écrit un script shell qui m'auto matise
> tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
peut-être démonter la clé $i ??
--
Fred.
steve a écrit :
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquel les je
> vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> pour un grand nombre de clés, j'ai écrit un script shell qui m'auto matise
> tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
peut-être démonter la clé $i ??
--
Fred.
Bonjour,
Suite de mon questionnement.
Je me demandais s'il était possible, plutôt que de faire les copies l'une
après l'autre (la boucle for), de les faire en parallèle, de manière à
réduire le temps total au temps de copie d'une seule clé.
Merci pour tout conseil, proposition, idée, etc...
Bonne journée
Bonjour,
Suite de mon questionnement.
Je me demandais s'il était possible, plutôt que de faire les copies l'une
après l'autre (la boucle for), de les faire en parallèle, de manière à
réduire le temps total au temps de copie d'une seule clé.
Merci pour tout conseil, proposition, idée, etc...
Bonne journée
Bonjour,
Suite de mon questionnement.
Je me demandais s'il était possible, plutôt que de faire les copies l'une
après l'autre (la boucle for), de les faire en parallèle, de manière à
réduire le temps total au temps de copie d'une seule clé.
Merci pour tout conseil, proposition, idée, etc...
Bonne journée