Hier, j'ai le MacBOOK Pro qui s'est éteint pendant sa veille... plus de
jus.
Je ne m'en suis pas aperçu tout de suite, et j'ai rebranché
l'alimentation. J'ai retrouvé intact le contenu de la RAM et j'ai pu
continuer à travailler.
C'est bien ça. C'est spécifique au MPB ? Le iBook G4 ne réagit pas tel
quel...
Ca m'étonnerait... Vu le "coût" d'accès au disque dur et étant donné que le contenu de la RAM change en permanence... (Pour dire les choses autrements : le disque dur est bien trop lent pour supporter ce genre de chose)
Il y a plutôt des choses qui se passent au moment de la mise en veille: la respiration de la loupiote blanche n'est pas immédiate, et on entend encore parfaitement le DD (ou les ventilos?) tourner alors que le capot est fermé; ça dure au bas mot 10 secondes, peut-être plus, avant que la veille soit bien installée.
En tout cas en 10 secondes on a pas le temps d'ecrire 1Go de RAM sur le DD.
-- Saïd. "Bless this, O Lord, that with it thou mayst blow thine enemies to tiny bits, in thy mercy." In the Book of Armaments, Chapter 4. (The Holy Hand Grenade)
Dominique Lang :
Franck <franck+news@_remove_apoal.com> wrote:
Ca m'étonnerait... Vu le "coût" d'accès au disque dur et étant donné que
le contenu de la RAM change en permanence... (Pour dire les choses
autrements : le disque dur est bien trop lent pour supporter ce genre de
chose)
Il y a plutôt des choses qui se passent au moment de la mise en veille:
la respiration de la loupiote blanche n'est pas immédiate, et on entend
encore parfaitement le DD (ou les ventilos?) tourner alors que le capot
est fermé; ça dure au bas mot 10 secondes, peut-être plus, avant que la
veille soit bien installée.
En tout cas en 10 secondes on a pas le temps d'ecrire 1Go de RAM sur le DD.
--
Saïd.
"Bless this, O Lord, that with it thou mayst blow thine enemies to tiny
bits, in thy mercy."
In the Book of Armaments, Chapter 4. (The Holy Hand Grenade)
Ca m'étonnerait... Vu le "coût" d'accès au disque dur et étant donné que le contenu de la RAM change en permanence... (Pour dire les choses autrements : le disque dur est bien trop lent pour supporter ce genre de chose)
Il y a plutôt des choses qui se passent au moment de la mise en veille: la respiration de la loupiote blanche n'est pas immédiate, et on entend encore parfaitement le DD (ou les ventilos?) tourner alors que le capot est fermé; ça dure au bas mot 10 secondes, peut-être plus, avant que la veille soit bien installée.
En tout cas en 10 secondes on a pas le temps d'ecrire 1Go de RAM sur le DD.
-- Saïd. "Bless this, O Lord, that with it thou mayst blow thine enemies to tiny bits, in thy mercy." In the Book of Armaments, Chapter 4. (The Holy Hand Grenade)
dominiquelang
Saïd wrote:
En tout cas en 10 secondes on a pas le temps d'ecrire 1Go de RAM sur le DD.
Je suis bien d'accord. Alors, que se passe-t-il (bon sang de bois)?
Admettre qu'il n'écrit que ce qui est occupé en RAM (Finder tout seul, par exemple)? -- Par principe, je doute de tout, sauf de ce dont je suis sûr. Remplacez FromMyTrailer.invalid par wanadoo.fr pour répondre en privé! Dominique Lang Gériatrie: <http://perso.wanadoo.fr/dominique.lang/accueil.html>
Saïd <said@brian.lan> wrote:
En tout cas en 10 secondes on a pas le temps d'ecrire 1Go de RAM sur le DD.
Je suis bien d'accord. Alors, que se passe-t-il (bon sang de bois)?
Admettre qu'il n'écrit que ce qui est occupé en RAM (Finder tout seul,
par exemple)?
--
Par principe, je doute de tout, sauf de ce dont je suis sûr.
Remplacez FromMyTrailer.invalid par wanadoo.fr pour répondre en privé!
Dominique Lang
Gériatrie: <http://perso.wanadoo.fr/dominique.lang/accueil.html>
En tout cas en 10 secondes on a pas le temps d'ecrire 1Go de RAM sur le DD.
Je suis bien d'accord. Alors, que se passe-t-il (bon sang de bois)?
Admettre qu'il n'écrit que ce qui est occupé en RAM (Finder tout seul, par exemple)? -- Par principe, je doute de tout, sauf de ce dont je suis sûr. Remplacez FromMyTrailer.invalid par wanadoo.fr pour répondre en privé! Dominique Lang Gériatrie: <http://perso.wanadoo.fr/dominique.lang/accueil.html>
nospam
Dominique Lang wrote:
Sur un PowerBook, faut redémarrer; sur le MBP, suffit de rebrancher le secteur.
Pas sur le mien. Tout dépend de la génération de powerbook. :-)
-- Jacques
Dominique Lang <dominiquelang@FromMyTrailer.invalid> wrote:
Sur un PowerBook, faut redémarrer; sur le MBP, suffit de rebrancher le
secteur.
Pas sur le mien. Tout dépend de la génération de powerbook. :-)
Sur un PowerBook, faut redémarrer; sur le MBP, suffit de rebrancher le secteur.
Pas sur le mien. Tout dépend de la génération de powerbook. :-)
-- Jacques
Saïd
Dominique Lang :
Saïd wrote:
En tout cas en 10 secondes on a pas le temps d'ecrire 1Go de RAM sur le DD.
Je suis bien d'accord. Alors, que se passe-t-il (bon sang de bois)?
Admettre qu'il n'écrit que ce qui est occupé en RAM (Finder tout seul, par exemple)?
Pense a toutes les applications inactives. Tant qu'elles ne changent rien a leur donnees en memoire, le systeme a tout le temps de sauvegarder celles-ci vers le DD.
En plus le cache en lecture du DD peut etre simplement ignore (je ne sais pas si c'est fait par mac OS X) vu que les donnees sont deja sur le DD. (*)
Les donnees dans le swap aussi (d'ou l'interet d'evoir un mauvaise gestion du swap ;-) ).
(*) Voici une experience:
choisir un gros fichier (100 Mo par exemple) sur un CD (je ne sais pas pourquoi ca ne marche pas un fichier sur mon DD...) dans le terminal:
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps A) time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps B) time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps BP) -> passer en veille vers DD (plus de jus) -> rallumer time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps C) Si C est plus proche de A que de B ou de BP c'est que le cache en lecture est simplement ignore.
Si tu pouvais poster A,B,BP et C. ca serait sympa. Dans le cas d'une veille normale (avec du jus) je viens de tester et je passe de 20 secondes pour A à 0.15s pour B BP et C.
-- Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser. Wer bleibt er? -- Heidegger
Dominique Lang :
Saïd <said@brian.lan> wrote:
En tout cas en 10 secondes on a pas le temps d'ecrire 1Go de RAM sur le DD.
Je suis bien d'accord. Alors, que se passe-t-il (bon sang de bois)?
Admettre qu'il n'écrit que ce qui est occupé en RAM (Finder tout seul,
par exemple)?
Pense a toutes les applications inactives. Tant qu'elles ne changent rien a
leur donnees en memoire, le systeme a tout le temps de sauvegarder celles-ci
vers le DD.
En plus le cache en lecture du DD peut etre simplement ignore (je ne sais
pas si c'est fait par mac OS X) vu que les donnees sont deja sur le DD. (*)
Les donnees dans le swap aussi (d'ou l'interet d'evoir un mauvaise gestion
du swap ;-) ).
(*) Voici une experience:
choisir un gros fichier (100 Mo par exemple) sur un CD (je ne sais pas
pourquoi ca ne marche pas un fichier sur mon DD...)
dans le terminal:
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps A)
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps B)
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps BP)
-> passer en veille vers DD (plus de jus)
-> rallumer
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps C)
Si C est plus proche de A que de B ou de BP c'est que le cache en lecture
est simplement ignore.
Si tu pouvais poster A,B,BP et C. ca serait sympa. Dans le cas d'une veille
normale (avec du jus) je viens de tester et je passe de 20 secondes pour A à
0.15s pour B BP et C.
--
Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser.
Wer bleibt er? -- Heidegger
En tout cas en 10 secondes on a pas le temps d'ecrire 1Go de RAM sur le DD.
Je suis bien d'accord. Alors, que se passe-t-il (bon sang de bois)?
Admettre qu'il n'écrit que ce qui est occupé en RAM (Finder tout seul, par exemple)?
Pense a toutes les applications inactives. Tant qu'elles ne changent rien a leur donnees en memoire, le systeme a tout le temps de sauvegarder celles-ci vers le DD.
En plus le cache en lecture du DD peut etre simplement ignore (je ne sais pas si c'est fait par mac OS X) vu que les donnees sont deja sur le DD. (*)
Les donnees dans le swap aussi (d'ou l'interet d'evoir un mauvaise gestion du swap ;-) ).
(*) Voici une experience:
choisir un gros fichier (100 Mo par exemple) sur un CD (je ne sais pas pourquoi ca ne marche pas un fichier sur mon DD...) dans le terminal:
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps A) time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps B) time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps BP) -> passer en veille vers DD (plus de jus) -> rallumer time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps C) Si C est plus proche de A que de B ou de BP c'est que le cache en lecture est simplement ignore.
Si tu pouvais poster A,B,BP et C. ca serait sympa. Dans le cas d'une veille normale (avec du jus) je viens de tester et je passe de 20 secondes pour A à 0.15s pour B BP et C.
-- Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser. Wer bleibt er? -- Heidegger
Franck
Pense a toutes les applications inactives.
Ca n'existe pas du point de vue système. Ce n'est pas parce qu'une application semble inactive qu'elle l'est.
Toutes les applications obtiennent à tour de rôle (sauf si l'ensemble des threads de celle-ci sont bloquées sur une opération d'entrée/sortie) un "slice" du CPU.
De toute façon, anticiper une éventuelle et improbable "hibernation" est une hérésie (et il faut bien s'imaginer que Apple à mis en place cette solution uniquement pour pallier à une défaillance de l'alimentation alors que le portable est *deja* en veille, donc ca doit arriver vraiment très rarement), donc le système ne le fait absolument pas.
Par contre il y a plusieurs solutions pour accélérer la sauvegarde de la mémoire :
- Le fichier de sauvegarde est pré-alloué avec une taille égale à la taille de la RAM. On évite donc de perdre du temps dans l'allocation de zones sur le disque à l'écriture. De plus on se débrouille pour allouer des blocs consécutifs sur le disque pour accélérer l'écriture.
- On ne sauvegarde évidemment que les pages mémoire marquées comme utilisées et non swapées. Aucun intéret à sauvegarder les pages "libres" ou swappées (vu qu'elles sont déjà dans un fichier sur disque).
Mac OS préalloue bien le fichier pour l'hibernation (par contre je n'ai pas vérifié s'il cherche vraiment à allouer un maximum de blocs consécutifs).
La led de mon powerbook se met à clignoter après quelques secondes quand je passe en veille juste après avoir démarré (mémoire utilisée : environ 200 Mo), et après plus de 15 secondes quand la mémoire consommée est supérieure à 1 Go), ce qui confirme la seconde hypothèse.
Pense a toutes les applications inactives.
Ca n'existe pas du point de vue système. Ce n'est pas parce qu'une
application semble inactive qu'elle l'est.
Toutes les applications obtiennent à tour de rôle (sauf si l'ensemble
des threads de celle-ci sont bloquées sur une opération d'entrée/sortie)
un "slice" du CPU.
De toute façon, anticiper une éventuelle et improbable "hibernation" est
une hérésie (et il faut bien s'imaginer que Apple à mis en place cette
solution uniquement pour pallier à une défaillance de l'alimentation
alors que le portable est *deja* en veille, donc ca doit arriver
vraiment très rarement), donc le système ne le fait absolument pas.
Par contre il y a plusieurs solutions pour accélérer la sauvegarde de la
mémoire :
- Le fichier de sauvegarde est pré-alloué avec une taille égale à la
taille de la RAM. On évite donc de perdre du temps dans l'allocation de
zones sur le disque à l'écriture. De plus on se débrouille pour allouer
des blocs consécutifs sur le disque pour accélérer l'écriture.
- On ne sauvegarde évidemment que les pages mémoire marquées comme
utilisées et non swapées. Aucun intéret à sauvegarder les pages "libres"
ou swappées (vu qu'elles sont déjà dans un fichier sur disque).
Mac OS préalloue bien le fichier pour l'hibernation (par contre je n'ai
pas vérifié s'il cherche vraiment à allouer un maximum de blocs
consécutifs).
La led de mon powerbook se met à clignoter après quelques secondes quand
je passe en veille juste après avoir démarré (mémoire utilisée : environ
200 Mo), et après plus de 15 secondes quand la mémoire consommée est
supérieure à 1 Go), ce qui confirme la seconde hypothèse.
Ca n'existe pas du point de vue système. Ce n'est pas parce qu'une application semble inactive qu'elle l'est.
Toutes les applications obtiennent à tour de rôle (sauf si l'ensemble des threads de celle-ci sont bloquées sur une opération d'entrée/sortie) un "slice" du CPU.
De toute façon, anticiper une éventuelle et improbable "hibernation" est une hérésie (et il faut bien s'imaginer que Apple à mis en place cette solution uniquement pour pallier à une défaillance de l'alimentation alors que le portable est *deja* en veille, donc ca doit arriver vraiment très rarement), donc le système ne le fait absolument pas.
Par contre il y a plusieurs solutions pour accélérer la sauvegarde de la mémoire :
- Le fichier de sauvegarde est pré-alloué avec une taille égale à la taille de la RAM. On évite donc de perdre du temps dans l'allocation de zones sur le disque à l'écriture. De plus on se débrouille pour allouer des blocs consécutifs sur le disque pour accélérer l'écriture.
- On ne sauvegarde évidemment que les pages mémoire marquées comme utilisées et non swapées. Aucun intéret à sauvegarder les pages "libres" ou swappées (vu qu'elles sont déjà dans un fichier sur disque).
Mac OS préalloue bien le fichier pour l'hibernation (par contre je n'ai pas vérifié s'il cherche vraiment à allouer un maximum de blocs consécutifs).
La led de mon powerbook se met à clignoter après quelques secondes quand je passe en veille juste après avoir démarré (mémoire utilisée : environ 200 Mo), et après plus de 15 secondes quand la mémoire consommée est supérieure à 1 Go), ce qui confirme la seconde hypothèse.
FiLH
Franck <franck+ writes:
Pense a toutes les applications inactives.
Ca n'existe pas du point de vue système.
Ben tiens ! L'état Sleep dans le scheduler il est fait pour les chiens ?
Par contre il y a plusieurs solutions pour accélérer la sauvegarde de la mémoire :
- Le fichier de sauvegarde est pré-alloué avec une taille égale à la taille de la RAM. On évite donc de perdre du temps dans l'allocation de zones sur le disque à l'écriture. De plus on se débrouille pour allouer des blocs consécutifs sur le disque pour accélérer l'écriture.
Ça c'est le cas sur pas mal d'OS, en fait on gère la mémoire comme du cache disque - il n'y a pas de grosse distinction entre la gestion des fichiers et de la mémoire.
- On ne sauvegarde évidemment que les pages mémoire marquées comme utilisées et non swapées. Aucun intéret à sauvegarder les pages "libres" ou swappées (vu qu'elles sont déjà dans un fichier sur disque).
C'est aussi le cas de base (heureusement : en cas de défaut de page on va pas écrire si il n'y en a pas besoin...).
200 Mo), et après plus de 15 secondes quand la mémoire consommée est supérieure à 1 Go), ce qui confirme la seconde hypothèse.
Ça confirme surtout qu'il y a un sacrès gros tas de mémoire qui est dèjà sauvergardé...
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Franck <franck+news@_remove_apoal.com> writes:
Pense a toutes les applications inactives.
Ca n'existe pas du point de vue système.
Ben tiens ! L'état Sleep dans le scheduler il est fait pour les chiens ?
Par contre il y a plusieurs solutions pour accélérer la sauvegarde de la
mémoire :
- Le fichier de sauvegarde est pré-alloué avec une taille égale à la
taille de la RAM. On évite donc de perdre du temps dans l'allocation de
zones sur le disque à l'écriture. De plus on se débrouille pour allouer
des blocs consécutifs sur le disque pour accélérer l'écriture.
Ça c'est le cas sur pas mal d'OS, en fait on gère la mémoire comme du
cache disque - il n'y a pas de grosse distinction entre la gestion des
fichiers et de la mémoire.
- On ne sauvegarde évidemment que les pages mémoire marquées comme
utilisées et non swapées. Aucun intéret à sauvegarder les pages "libres"
ou swappées (vu qu'elles sont déjà dans un fichier sur disque).
C'est aussi le cas de base (heureusement : en cas de défaut de page on
va pas écrire si il n'y en a pas besoin...).
200 Mo), et après plus de 15 secondes quand la mémoire consommée est
supérieure à 1 Go), ce qui confirme la seconde hypothèse.
Ça confirme surtout qu'il y a un sacrès gros tas de mémoire qui est
dèjà sauvergardé...
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Ben tiens ! L'état Sleep dans le scheduler il est fait pour les chiens ?
Par contre il y a plusieurs solutions pour accélérer la sauvegarde de la mémoire :
- Le fichier de sauvegarde est pré-alloué avec une taille égale à la taille de la RAM. On évite donc de perdre du temps dans l'allocation de zones sur le disque à l'écriture. De plus on se débrouille pour allouer des blocs consécutifs sur le disque pour accélérer l'écriture.
Ça c'est le cas sur pas mal d'OS, en fait on gère la mémoire comme du cache disque - il n'y a pas de grosse distinction entre la gestion des fichiers et de la mémoire.
- On ne sauvegarde évidemment que les pages mémoire marquées comme utilisées et non swapées. Aucun intéret à sauvegarder les pages "libres" ou swappées (vu qu'elles sont déjà dans un fichier sur disque).
C'est aussi le cas de base (heureusement : en cas de défaut de page on va pas écrire si il n'y en a pas besoin...).
200 Mo), et après plus de 15 secondes quand la mémoire consommée est supérieure à 1 Go), ce qui confirme la seconde hypothèse.
Ça confirme surtout qu'il y a un sacrès gros tas de mémoire qui est dèjà sauvergardé...
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
dominiquelang
Jacques Foucry wrote:
Pas sur le mien. Tout dépend de la génération de powerbook. :-)
Tricheur. ;-)
PB G4 667 MHz. Je sais. Une antiquité. -- Par principe, je doute de tout, sauf de ce dont je suis sûr. Remplacez FromMyTrailer.invalid par wanadoo.fr pour répondre en privé! Dominique Lang Gériatrie: <http://perso.wanadoo.fr/dominique.lang/accueil.html>
Jacques Foucry <nospam@foucry.net.invalid> wrote:
Pas sur le mien. Tout dépend de la génération de powerbook. :-)
Tricheur. ;-)
PB G4 667 MHz. Je sais. Une antiquité.
--
Par principe, je doute de tout, sauf de ce dont je suis sûr.
Remplacez FromMyTrailer.invalid par wanadoo.fr pour répondre en privé!
Dominique Lang
Gériatrie: <http://perso.wanadoo.fr/dominique.lang/accueil.html>
Pas sur le mien. Tout dépend de la génération de powerbook. :-)
Tricheur. ;-)
PB G4 667 MHz. Je sais. Une antiquité. -- Par principe, je doute de tout, sauf de ce dont je suis sûr. Remplacez FromMyTrailer.invalid par wanadoo.fr pour répondre en privé! Dominique Lang Gériatrie: <http://perso.wanadoo.fr/dominique.lang/accueil.html>
dominiquelang
Saïd wrote:
choisir un gros fichier (100 Mo par exemple) sur un CD (je ne sais pas pourquoi ca ne marche pas un fichier sur mon DD...) dans le terminal:
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps A) time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps B) time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps BP) -> passer en veille vers DD (plus de jus) -> rallumer time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps C) Si C est plus proche de A que de B ou de BP c'est que le cache en lecture est simplement ignore.
Je pige pas les lignes de commande. Où figure le fichier choisi sur le cédé?
Pourquoi trois temps différents (I suppose) pour des lignes de commande identique?
J'aime bien comprendre ce que j'ordonne, même à une machine... ;-) -- Par principe, je doute de tout, sauf de ce dont je suis sûr. Remplacez FromMyTrailer.invalid par wanadoo.fr pour répondre en privé! Dominique Lang Gériatrie: <http://perso.wanadoo.fr/dominique.lang/accueil.html>
Saïd <said@brian.lan> wrote:
choisir un gros fichier (100 Mo par exemple) sur un CD (je ne sais pas
pourquoi ca ne marche pas un fichier sur mon DD...)
dans le terminal:
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps A)
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps B)
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps BP)
-> passer en veille vers DD (plus de jus)
-> rallumer
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps C)
Si C est plus proche de A que de B ou de BP c'est que le cache en lecture
est simplement ignore.
Je pige pas les lignes de commande. Où figure le fichier choisi sur le
cédé?
Pourquoi trois temps différents (I suppose) pour des lignes de commande
identique?
J'aime bien comprendre ce que j'ordonne, même à une machine... ;-)
--
Par principe, je doute de tout, sauf de ce dont je suis sûr.
Remplacez FromMyTrailer.invalid par wanadoo.fr pour répondre en privé!
Dominique Lang
Gériatrie: <http://perso.wanadoo.fr/dominique.lang/accueil.html>
choisir un gros fichier (100 Mo par exemple) sur un CD (je ne sais pas pourquoi ca ne marche pas un fichier sur mon DD...) dans le terminal:
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps A) time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps B) time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps BP) -> passer en veille vers DD (plus de jus) -> rallumer time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps C) Si C est plus proche de A que de B ou de BP c'est que le cache en lecture est simplement ignore.
Je pige pas les lignes de commande. Où figure le fichier choisi sur le cédé?
Pourquoi trois temps différents (I suppose) pour des lignes de commande identique?
J'aime bien comprendre ce que j'ordonne, même à une machine... ;-) -- Par principe, je doute de tout, sauf de ce dont je suis sûr. Remplacez FromMyTrailer.invalid par wanadoo.fr pour répondre en privé! Dominique Lang Gériatrie: <http://perso.wanadoo.fr/dominique.lang/accueil.html>
Saïd
Dominique Lang :
Saïd wrote:
choisir un gros fichier (100 Mo par exemple) sur un CD (je ne sais pas pourquoi ca ne marche pas un fichier sur mon DD...) dans le terminal:
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps A) time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps B) time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps BP) -> passer en veille vers DD (plus de jus) -> rallumer time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps C) Si C est plus proche de A que de B ou de BP c'est que le cache en lecture est simplement ignore.
Je pige pas les lignes de commande. Où figure le fichier choisi sur le cédé?
Pourquoi trois temps différents (I suppose) pour des lignes de commande identique?
Parce qu'on lit une partie du fichier. Le systeme sait qu'un lecteur de CD c'est lent et se dit que si on veut reacceder a cette meme partie plus tard il vaut mieux la stocker en memoire. Du coup B et Bp devraient etre tres petits par rapport a A (20 secondes pour A =premiere lecture 0.15 secondes pour B, BP et C chez moi, mais j'utilise une veille simple)
J'aime bien comprendre ce que j'ordonne, même à une machine... ;-)
man dd :)
-- Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser. Wer bleibt er? -- Heidegger
Dominique Lang :
Saïd <said@brian.lan> wrote:
choisir un gros fichier (100 Mo par exemple) sur un CD (je ne sais pas
pourquoi ca ne marche pas un fichier sur mon DD...)
dans le terminal:
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps A)
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps B)
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps BP)
-> passer en veille vers DD (plus de jus)
-> rallumer
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps C)
Si C est plus proche de A que de B ou de BP c'est que le cache en lecture
est simplement ignore.
Je pige pas les lignes de commande. Où figure le fichier choisi sur le
cédé?
Pourquoi trois temps différents (I suppose) pour des lignes de commande
identique?
Parce qu'on lit une partie du fichier. Le systeme sait qu'un lecteur de CD
c'est lent et se dit que si on veut reacceder a cette meme partie plus tard
il vaut mieux la stocker en memoire. Du coup B et Bp devraient etre tres
petits par rapport a A (20 secondes pour A =premiere lecture 0.15 secondes
pour B, BP et C chez moi, mais j'utilise une veille simple)
J'aime bien comprendre ce que j'ordonne, même à une machine... ;-)
man dd :)
--
Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser.
Wer bleibt er? -- Heidegger
choisir un gros fichier (100 Mo par exemple) sur un CD (je ne sais pas pourquoi ca ne marche pas un fichier sur mon DD...) dans le terminal:
time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps A) time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps B) time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps BP) -> passer en veille vers DD (plus de jus) -> rallumer time dd if=fichier of=/dev/null count0 bs00000 (renvoie un temps C) Si C est plus proche de A que de B ou de BP c'est que le cache en lecture est simplement ignore.
Je pige pas les lignes de commande. Où figure le fichier choisi sur le cédé?
Pourquoi trois temps différents (I suppose) pour des lignes de commande identique?
Parce qu'on lit une partie du fichier. Le systeme sait qu'un lecteur de CD c'est lent et se dit que si on veut reacceder a cette meme partie plus tard il vaut mieux la stocker en memoire. Du coup B et Bp devraient etre tres petits par rapport a A (20 secondes pour A =premiere lecture 0.15 secondes pour B, BP et C chez moi, mais j'utilise une veille simple)
J'aime bien comprendre ce que j'ordonne, même à une machine... ;-)
man dd :)
-- Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser. Wer bleibt er? -- Heidegger
