--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Si c'est un bug, d'où vient-il? Du noyau? De l'utilitaire time qui ne fait pas telle ou telle correction nécessaire?
A mon avis ce n'est pas un bogue. La commande time doit s'appuyer sur l'appel système times ou getrusage qui renvoie le temps CPU, et lorsqu'on a plus d'un processeur (cas des multicores actuels) qui travaille sur le processus mesuré (ainsi que ses fils et ses threads!) le temps cpu est supérieur au temps réel. Par exemple, si les 2 processeurs tournent à fond pendant une seconde, le temps cpu sera de 2 secondes.
Par contre, le temps mesuré n'est vraiement significatif que s'il a été suffisamment echantillonné. Il faudrait donc lancer une commande qui prend un certain temps (typiquement plus d'une seconde de CPU) pour que la mesure soit significative.
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre wrote:
Est-ce que c'est normal d'avoir un temps CPU > 100%?
Si c'est un bug, d'où vient-il? Du noyau? De l'utilitaire time qui ne
fait pas telle ou telle correction nécessaire?
A mon avis ce n'est pas un bogue. La commande time doit s'appuyer sur
l'appel système times ou getrusage qui renvoie le temps CPU, et
lorsqu'on a plus d'un processeur (cas des multicores actuels) qui
travaille sur le processus mesuré (ainsi que ses fils et ses threads!)
le temps cpu est supérieur au temps réel. Par exemple, si les 2
processeurs tournent à fond pendant une seconde, le temps cpu sera de 2
secondes.
Par contre, le temps mesuré n'est vraiement significatif que s'il a été
suffisamment echantillonné. Il faudrait donc lancer une commande qui
prend un certain temps (typiquement plus d'une seconde de CPU) pour que
la mesure soit significative.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Si c'est un bug, d'où vient-il? Du noyau? De l'utilitaire time qui ne fait pas telle ou telle correction nécessaire?
A mon avis ce n'est pas un bogue. La commande time doit s'appuyer sur l'appel système times ou getrusage qui renvoie le temps CPU, et lorsqu'on a plus d'un processeur (cas des multicores actuels) qui travaille sur le processus mesuré (ainsi que ses fils et ses threads!) le temps cpu est supérieur au temps réel. Par exemple, si les 2 processeurs tournent à fond pendant une seconde, le temps cpu sera de 2 secondes.
Par contre, le temps mesuré n'est vraiement significatif que s'il a été suffisamment echantillonné. Il faudrait donc lancer une commande qui prend un certain temps (typiquement plus d'une seconde de CPU) pour que la mesure soit significative.
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre
On 2008-05-19 15:18:59 +0200, Basile STARYNKEVITCH wrote:
A mon avis ce n'est pas un bogue. La commande time doit s'appuyer sur l'appel système times ou getrusage qui renvoie le temps CPU, et lorsqu'on a plus d'un processeur (cas des multicores actuels) qui travaille sur le processus mesuré (ainsi que ses fils et ses threads!)
La machine a plus d'un processeur, mais je précise que le processus ne fait pas de fork, et il ne crée pas de threads non plus. C'est un programme C standard (ISO C99) tout bête.
le temps cpu est supérieur au temps réel. Par exemple, si les 2 processeurs tournent à fond pendant une seconde, le temps cpu sera de 2 secondes.
Par contre, le temps mesuré n'est vraiement significatif que s'il a été suffisamment echantillonné. Il faudrait donc lancer une commande qui prend un certain temps (typiquement plus d'une seconde de CPU) pour que la mesure soit significative.
Oui, c'est la source du problème, et d'ailleurs dès que la commande prend plus de temps (valeur donnée en argument plus élevée), le temps CPU est bien toujours <= 100%.
Note: je sais bien que c'est imprécis, mais la commande time ne devrait-elle pas fournir un comportement *cohérent* avec la réalité?
Je vois deux raisons à vouloir un résultat cohérent: _ Pour les humains, qui peuvent se poser des questions lorsqu'une valeur > 100% est obtenue. _ Pour les programmes, lorsque la sortie de time est traitée par un autre programme: celui-ci risque de se comporter de manière erratique, voire quelque chose de plus sérieux comme un buffer overflow.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On 2008-05-19 15:18:59 +0200, Basile STARYNKEVITCH wrote:
A mon avis ce n'est pas un bogue. La commande time doit s'appuyer sur
l'appel système times ou getrusage qui renvoie le temps CPU, et
lorsqu'on a plus d'un processeur (cas des multicores actuels) qui
travaille sur le processus mesuré (ainsi que ses fils et ses threads!)
La machine a plus d'un processeur, mais je précise que le processus
ne fait pas de fork, et il ne crée pas de threads non plus. C'est un
programme C standard (ISO C99) tout bête.
le temps cpu est supérieur au temps réel. Par exemple, si les 2
processeurs tournent à fond pendant une seconde, le temps cpu sera de 2
secondes.
Par contre, le temps mesuré n'est vraiement significatif que s'il a été
suffisamment echantillonné. Il faudrait donc lancer une commande qui
prend un certain temps (typiquement plus d'une seconde de CPU) pour que
la mesure soit significative.
Oui, c'est la source du problème, et d'ailleurs dès que la commande
prend plus de temps (valeur donnée en argument plus élevée), le temps
CPU est bien toujours <= 100%.
Note: je sais bien que c'est imprécis, mais la commande time ne
devrait-elle pas fournir un comportement *cohérent* avec la réalité?
Je vois deux raisons à vouloir un résultat cohérent:
_ Pour les humains, qui peuvent se poser des questions lorsqu'une
valeur > 100% est obtenue.
_ Pour les programmes, lorsque la sortie de time est traitée par
un autre programme: celui-ci risque de se comporter de manière
erratique, voire quelque chose de plus sérieux comme un buffer
overflow.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On 2008-05-19 15:18:59 +0200, Basile STARYNKEVITCH wrote:
A mon avis ce n'est pas un bogue. La commande time doit s'appuyer sur l'appel système times ou getrusage qui renvoie le temps CPU, et lorsqu'on a plus d'un processeur (cas des multicores actuels) qui travaille sur le processus mesuré (ainsi que ses fils et ses threads!)
La machine a plus d'un processeur, mais je précise que le processus ne fait pas de fork, et il ne crée pas de threads non plus. C'est un programme C standard (ISO C99) tout bête.
le temps cpu est supérieur au temps réel. Par exemple, si les 2 processeurs tournent à fond pendant une seconde, le temps cpu sera de 2 secondes.
Par contre, le temps mesuré n'est vraiement significatif que s'il a été suffisamment echantillonné. Il faudrait donc lancer une commande qui prend un certain temps (typiquement plus d'une seconde de CPU) pour que la mesure soit significative.
Oui, c'est la source du problème, et d'ailleurs dès que la commande prend plus de temps (valeur donnée en argument plus élevée), le temps CPU est bien toujours <= 100%.
Note: je sais bien que c'est imprécis, mais la commande time ne devrait-elle pas fournir un comportement *cohérent* avec la réalité?
Je vois deux raisons à vouloir un résultat cohérent: _ Pour les humains, qui peuvent se poser des questions lorsqu'une valeur > 100% est obtenue. _ Pour les programmes, lorsque la sortie de time est traitée par un autre programme: celui-ci risque de se comporter de manière erratique, voire quelque chose de plus sérieux comme un buffer overflow.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Basile STARYNKEVITCH
Vincent Lefevre wrote:
On 2008-05-19 15:18:59 +0200, Basile STARYNKEVITCH wrote:
Par contre, le temps mesuré n'est vraiement significatif que s'il a été suffisamment echantillonné. Il faudrait donc lancer une commande qui prend un certain temps (typiquement plus d'une seconde de CPU) pour que la mesure soit significative.
Oui, c'est la source du problème, et d'ailleurs dès que la commande prend plus de temps (valeur donnée en argument plus élevée), le temps CPU est bien toujours <= 100%.
Note: je sais bien que c'est imprécis, mais la commande time ne devrait-elle pas fournir un comportement *cohérent* avec la réalité?
Ce n'est pas dans la philosophie d'Unix, au moins à son origine.
A l'époque, on cherchait plutot à implémenter simplement. Une implémentation simple serait par exemple
le processeur (ou un autre matériel) émet une interruption temporelle à chaque milliseconde la mesure du temps CPU, et une autre sorte d'interruption temporelle à chaque centiseconde (qui ne tombe pas en même temps que la précédente) pour la mesure du temps d'horloge (temps "réel").
L'ordonnanceur du noyau:
quand il recoit une interruption temporelle pour la CPU (chaque milliseconde) incrémente un compteur dans le description de tache courante et réordonne les processus (donc en active un autre).
quand il reçoit une interruption temporelle pour le temps d'horloge (chaque centiseconde) incémente un compteur global (servant à la mesure du temps) et réordonne les processus.
Il me semble quand dans un tel cas il existe un scénario (un peu pathologique) où ton processus a deux ou trois top de temps CPU mais un seul (voire aucun) top de temps horloge.
Je suis donc suffisamment vieux pour ne pas être choqué par le temps CPU > 100%.
Je n'exige pas du noyau qu'il soit cohérent, mais qu'il marche à peu près. Et quand tu songes qu'il doit faire quelque chose quand on dérègle l'heure (et là ça devient compliqué), ou quand le processeur se ralentit, ça me suffit. J'ai autrefois lu un papier décrivant un algorithme de synchronisation d'horloge, je n'ai rien compris (c'est trop matheux pour moi) et j'ai eu la migraine. Dans le détail, c'est un métier!
Tu peux toujours réécrire time (utilisant getrusage ou times) qui te retourne toujours une charge CPU < 100% (par exemple quand les temps mesurés sont moins que la demiseconde, retourner une charge aléatoire entre 0 et 100%).
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre wrote:
On 2008-05-19 15:18:59 +0200, Basile STARYNKEVITCH wrote:
Par contre, le temps mesuré n'est vraiement significatif que s'il a été
suffisamment echantillonné. Il faudrait donc lancer une commande qui
prend un certain temps (typiquement plus d'une seconde de CPU) pour que
la mesure soit significative.
Oui, c'est la source du problème, et d'ailleurs dès que la commande
prend plus de temps (valeur donnée en argument plus élevée), le temps
CPU est bien toujours <= 100%.
Note: je sais bien que c'est imprécis, mais la commande time ne
devrait-elle pas fournir un comportement *cohérent* avec la réalité?
Ce n'est pas dans la philosophie d'Unix, au moins à son origine.
A l'époque, on cherchait plutot à implémenter simplement. Une
implémentation simple serait par exemple
le processeur (ou un autre matériel) émet une interruption temporelle à
chaque milliseconde la mesure du temps CPU, et une autre sorte
d'interruption temporelle à chaque centiseconde (qui ne tombe pas en
même temps que la précédente) pour la mesure du temps d'horloge (temps
"réel").
L'ordonnanceur du noyau:
quand il recoit une interruption temporelle pour la CPU (chaque
milliseconde) incrémente un compteur dans le description de tache
courante et réordonne les processus (donc en active un autre).
quand il reçoit une interruption temporelle pour le temps d'horloge
(chaque centiseconde) incémente un compteur global (servant à la mesure
du temps) et réordonne les processus.
Il me semble quand dans un tel cas il existe un scénario (un peu
pathologique) où ton processus a deux ou trois top de temps CPU mais un
seul (voire aucun) top de temps horloge.
Je suis donc suffisamment vieux pour ne pas être choqué par le temps CPU
> 100%.
Je n'exige pas du noyau qu'il soit cohérent, mais qu'il marche à peu
près. Et quand tu songes qu'il doit faire quelque chose quand on dérègle
l'heure (et là ça devient compliqué), ou quand le processeur se
ralentit, ça me suffit. J'ai autrefois lu un papier décrivant un
algorithme de synchronisation d'horloge, je n'ai rien compris (c'est
trop matheux pour moi) et j'ai eu la migraine. Dans le détail, c'est un
métier!
Tu peux toujours réécrire time (utilisant getrusage ou times) qui te
retourne toujours une charge CPU < 100% (par exemple quand les temps
mesurés sont moins que la demiseconde, retourner une charge aléatoire
entre 0 et 100%).
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On 2008-05-19 15:18:59 +0200, Basile STARYNKEVITCH wrote:
Par contre, le temps mesuré n'est vraiement significatif que s'il a été suffisamment echantillonné. Il faudrait donc lancer une commande qui prend un certain temps (typiquement plus d'une seconde de CPU) pour que la mesure soit significative.
Oui, c'est la source du problème, et d'ailleurs dès que la commande prend plus de temps (valeur donnée en argument plus élevée), le temps CPU est bien toujours <= 100%.
Note: je sais bien que c'est imprécis, mais la commande time ne devrait-elle pas fournir un comportement *cohérent* avec la réalité?
Ce n'est pas dans la philosophie d'Unix, au moins à son origine.
A l'époque, on cherchait plutot à implémenter simplement. Une implémentation simple serait par exemple
le processeur (ou un autre matériel) émet une interruption temporelle à chaque milliseconde la mesure du temps CPU, et une autre sorte d'interruption temporelle à chaque centiseconde (qui ne tombe pas en même temps que la précédente) pour la mesure du temps d'horloge (temps "réel").
L'ordonnanceur du noyau:
quand il recoit une interruption temporelle pour la CPU (chaque milliseconde) incrémente un compteur dans le description de tache courante et réordonne les processus (donc en active un autre).
quand il reçoit une interruption temporelle pour le temps d'horloge (chaque centiseconde) incémente un compteur global (servant à la mesure du temps) et réordonne les processus.
Il me semble quand dans un tel cas il existe un scénario (un peu pathologique) où ton processus a deux ou trois top de temps CPU mais un seul (voire aucun) top de temps horloge.
Je suis donc suffisamment vieux pour ne pas être choqué par le temps CPU > 100%.
Je n'exige pas du noyau qu'il soit cohérent, mais qu'il marche à peu près. Et quand tu songes qu'il doit faire quelque chose quand on dérègle l'heure (et là ça devient compliqué), ou quand le processeur se ralentit, ça me suffit. J'ai autrefois lu un papier décrivant un algorithme de synchronisation d'horloge, je n'ai rien compris (c'est trop matheux pour moi) et j'ai eu la migraine. Dans le détail, c'est un métier!
Tu peux toujours réécrire time (utilisant getrusage ou times) qui te retourne toujours une charge CPU < 100% (par exemple quand les temps mesurés sont moins que la demiseconde, retourner une charge aléatoire entre 0 et 100%).
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre
On 2008-05-19 17:16:46 +0200, Basile STARYNKEVITCH wrote:
Je n'exige pas du noyau qu'il soit cohérent, mais qu'il marche à peu près.
En fait, ce n'est probablement pas corrigeable dans le noyau, auquel cas c'est à la commande time (c'est d'ailleurs cette commande qui va faire le lien entre les deux types de temps) de s'occuper du problème, surtout que la documentation est plutôt floue.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On 2008-05-19 17:16:46 +0200, Basile STARYNKEVITCH wrote:
Je n'exige pas du noyau qu'il soit cohérent, mais qu'il marche à peu
près.
En fait, ce n'est probablement pas corrigeable dans le noyau, auquel
cas c'est à la commande time (c'est d'ailleurs cette commande qui va
faire le lien entre les deux types de temps) de s'occuper du problème,
surtout que la documentation est plutôt floue.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On 2008-05-19 17:16:46 +0200, Basile STARYNKEVITCH wrote:
Je n'exige pas du noyau qu'il soit cohérent, mais qu'il marche à peu près.
En fait, ce n'est probablement pas corrigeable dans le noyau, auquel cas c'est à la commande time (c'est d'ailleurs cette commande qui va faire le lien entre les deux types de temps) de s'occuper du problème, surtout que la documentation est plutôt floue.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
