Bonjour
je voudrais savoir (j'ai déjà posé la question, mais sans réponse
utilisable) si on peu imposer un max d'occupation proc à un process
particulier ?
style (dans mes rêves) : lp -p 80 /usr/bin/toto qui limiterait a 80%
d'occupation proc le processu lancé par /usr/bin/toto
"EMMANUEL DESSAUX" a écrit dans le message de news:
"Michel Talon" a écrit dans le message de news: bqi6lc$2c24$
EMMANUEL DESSAUX wrote:
Michel TALON
est ce qu'avec lmule, j'ai toutes les focntionalités d'xmule ? j'ai cru comprendre que lmule était full-ligne de commande, si c'est vrai,
est-ce quand même lisible (progression de fichier etc...)
Non lmule est complètement graphique (wxwindows) et parfaitement
semblable à emule sous windows.
--
Michel TALON
ah, et as tu déjà comparé lmule et xmule , parce du coup je vois pas en quoi
ca diffère je dis pas ca dans le vent, si lmule est plus leger mais aussi bien, j'y passerai peu etre, et pourquoi pas essayer (pour voir) de faire rourner les
deux en même temps :-))p)
je me réponds, xmule est le successeur de lmule :-) (un p'tit coup de google, ca aide :-)
"EMMANUEL DESSAUX" <emmanuel.dessaux@usinor.com> a écrit dans le message de
news: 3810FD4EAD8AD611A50D00805F0DA7FA045244A3@proxyusinor.usinor.com...
"Michel Talon" <talon@lpthe.jussieu.fr> a écrit dans le message de news:
bqi6lc$2c24$1@asmodee.lpthe.jussieu.fr...
est ce qu'avec lmule, j'ai toutes les focntionalités d'xmule ?
j'ai cru comprendre que lmule était full-ligne de commande, si c'est
vrai,
est-ce quand même lisible (progression de fichier etc...)
Non lmule est complètement graphique (wxwindows) et parfaitement
semblable à emule sous windows.
--
Michel TALON
ah, et as tu déjà comparé lmule et xmule , parce du coup je vois pas en
quoi
ca diffère
je dis pas ca dans le vent, si lmule est plus leger mais aussi bien, j'y
passerai peu etre, et pourquoi pas essayer (pour voir) de faire rourner
les
deux en même temps :-))p)
je me réponds, xmule est le successeur de lmule :-) (un p'tit coup de
google, ca aide :-)
"EMMANUEL DESSAUX" a écrit dans le message de news:
"Michel Talon" a écrit dans le message de news: bqi6lc$2c24$
EMMANUEL DESSAUX wrote:
Michel TALON
est ce qu'avec lmule, j'ai toutes les focntionalités d'xmule ? j'ai cru comprendre que lmule était full-ligne de commande, si c'est vrai,
est-ce quand même lisible (progression de fichier etc...)
Non lmule est complètement graphique (wxwindows) et parfaitement
semblable à emule sous windows.
--
Michel TALON
ah, et as tu déjà comparé lmule et xmule , parce du coup je vois pas en quoi
ca diffère je dis pas ca dans le vent, si lmule est plus leger mais aussi bien, j'y passerai peu etre, et pourquoi pas essayer (pour voir) de faire rourner les
deux en même temps :-))p)
je me réponds, xmule est le successeur de lmule :-) (un p'tit coup de google, ca aide :-)
Lo
"EMMANUEL DESSAUX" a écrit
Nice !!! Tu as tout a fait raison sur le fond, autant utiliser le proc à 100%, et même si j'ai bien vu qu'ne lancant une autre tâche, le taux d'occupation d'xmule (puisqu'il sagit de lui) baissait, j'ai tout de même ressenti de serieux ralentissements. et comme, dans le cas d'xmule, j'ai le temps, alors que pour le reste, je veus des réponses rapides, j'aurais voulu le limiter carrement a 50% du proc.
Tu as un kernel multimedia comme ils disent chez mandrake ? Un truc avec des patchs low-latencies etc ? Ca ameliore grandement le "ressenti des ralentissements" comme le curseur de la souris qui se traine lamentablement. En tout cas _chez moi_ le feeling est sensiblement meilleur. J'ai essayé un kernel 2.6 hier et je dois dire que sur les petits tests que j'ai fait, ca à l'air encore mieux.
Loic.
"EMMANUEL DESSAUX" a écrit
Nice !!!
Tu as tout a fait raison sur le fond, autant utiliser le proc à 100%, et
même si j'ai bien vu qu'ne lancant une autre tâche, le taux d'occupation
d'xmule (puisqu'il sagit de lui) baissait, j'ai tout de même ressenti de
serieux ralentissements.
et comme, dans le cas d'xmule, j'ai le temps, alors que pour le reste, je
veus des réponses rapides, j'aurais voulu le limiter carrement a 50% du
proc.
Tu as un kernel multimedia comme ils disent chez mandrake ? Un truc avec des
patchs low-latencies etc ? Ca ameliore grandement le "ressenti des
ralentissements" comme le curseur de la souris qui se traine lamentablement.
En tout cas _chez moi_ le feeling est sensiblement meilleur. J'ai essayé un
kernel 2.6 hier et je dois dire que sur les petits tests que j'ai fait, ca à
l'air encore mieux.
Nice !!! Tu as tout a fait raison sur le fond, autant utiliser le proc à 100%, et même si j'ai bien vu qu'ne lancant une autre tâche, le taux d'occupation d'xmule (puisqu'il sagit de lui) baissait, j'ai tout de même ressenti de serieux ralentissements. et comme, dans le cas d'xmule, j'ai le temps, alors que pour le reste, je veus des réponses rapides, j'aurais voulu le limiter carrement a 50% du proc.
Tu as un kernel multimedia comme ils disent chez mandrake ? Un truc avec des patchs low-latencies etc ? Ca ameliore grandement le "ressenti des ralentissements" comme le curseur de la souris qui se traine lamentablement. En tout cas _chez moi_ le feeling est sensiblement meilleur. J'ai essayé un kernel 2.6 hier et je dois dire que sur les petits tests que j'ai fait, ca à l'air encore mieux.
Loic.
george
"EMMANUEL DESSAUX" , dans le message , a écrit :
et pourquoi pas essayer (pour voir) de faire rourner les deux en même temps :-))p)
Parce qu'ils utilisent certainement les mêmes well-known ports.
"EMMANUEL DESSAUX" , dans le message
<3810FD4EAD8AD611A50D00805F0DA7FA045244A3@proxyusinor.usinor.com>, a
écrit :
et pourquoi pas essayer (pour voir) de faire rourner les
deux en même temps :-))p)
Parce qu'ils utilisent certainement les mêmes well-known ports.
et pourquoi pas essayer (pour voir) de faire rourner les deux en même temps :-))p)
Parce qu'ils utilisent certainement les mêmes well-known ports.
Jérémy JUST
On Tue, 02 Dec 2003 13:52:36 +0100 Rakotomandimby wrote:
non et re non . c'est pas jouable comme ça . :-)
Pour Linux, je ne sais pas, mais pour d'autres OS (commerciaux), c'est possible. On peut affecter un certain nombre d'applications ou d'utilisateurs à un sous-ensemble des ressources de la machine (CPU et RAM).
Par exemple, le groupe d'utilisateurs "calc" n'aura droit qu'à 40 CPU sur 48 et 192 Go de RAM sur 256 pour ses applications de calcul, ce qui laisse 4 CPU et un peu de RAM pour les xterm, Emacs, etc, de tout le monde, et toutes les applis des autres utilisateurs. C'est indispensable pour garantir l'utilisabilité des applications interactives, quand elles sont en concurrence avec des applis de calcul intensif.
Bon, après, pour un pauvre logiciel de peer-to-peer...
pas limiter l'occupation CPU , sans quoi ça serai le paradis ... en effet un process qui plante en boucle infinie serai non bloquant , or ce n'est le cas nulle part.
Ben si, avec le bon matériel. Même sous Linux, en pratique, je n'ai vu planter que des applications mono-thread ou bien un seul thread d'une application multithreadée. Donc le plantage ne phagocyte qu'un seul processeur.
-- Jérémy JUST
On Tue, 02 Dec 2003 13:52:36 +0100
Rakotomandimby <mrakotom@free.fr> wrote:
non et re non . c'est pas jouable comme ça . :-)
Pour Linux, je ne sais pas, mais pour d'autres OS (commerciaux), c'est
possible. On peut affecter un certain nombre d'applications ou
d'utilisateurs à un sous-ensemble des ressources de la machine (CPU et
RAM).
Par exemple, le groupe d'utilisateurs "calc" n'aura droit qu'à 40 CPU
sur 48 et 192 Go de RAM sur 256 pour ses applications de calcul, ce qui
laisse 4 CPU et un peu de RAM pour les xterm, Emacs, etc, de tout le
monde, et toutes les applis des autres utilisateurs.
C'est indispensable pour garantir l'utilisabilité des applications
interactives, quand elles sont en concurrence avec des applis de calcul
intensif.
Bon, après, pour un pauvre logiciel de peer-to-peer...
pas limiter l'occupation CPU , sans quoi ça serai le paradis ... en
effet un process qui plante en boucle infinie serai non bloquant , or ce
n'est le cas nulle part.
Ben si, avec le bon matériel.
Même sous Linux, en pratique, je n'ai vu planter que des applications
mono-thread ou bien un seul thread d'une application multithreadée. Donc
le plantage ne phagocyte qu'un seul processeur.
On Tue, 02 Dec 2003 13:52:36 +0100 Rakotomandimby wrote:
non et re non . c'est pas jouable comme ça . :-)
Pour Linux, je ne sais pas, mais pour d'autres OS (commerciaux), c'est possible. On peut affecter un certain nombre d'applications ou d'utilisateurs à un sous-ensemble des ressources de la machine (CPU et RAM).
Par exemple, le groupe d'utilisateurs "calc" n'aura droit qu'à 40 CPU sur 48 et 192 Go de RAM sur 256 pour ses applications de calcul, ce qui laisse 4 CPU et un peu de RAM pour les xterm, Emacs, etc, de tout le monde, et toutes les applis des autres utilisateurs. C'est indispensable pour garantir l'utilisabilité des applications interactives, quand elles sont en concurrence avec des applis de calcul intensif.
Bon, après, pour un pauvre logiciel de peer-to-peer...
pas limiter l'occupation CPU , sans quoi ça serai le paradis ... en effet un process qui plante en boucle infinie serai non bloquant , or ce n'est le cas nulle part.
Ben si, avec le bon matériel. Même sous Linux, en pratique, je n'ai vu planter que des applications mono-thread ou bien un seul thread d'une application multithreadée. Donc le plantage ne phagocyte qu'un seul processeur.
