Sujet: Universe@home - UT bloquées

[maxymus83]

Help 

C'est fou le nombre d'UT bloquées sur Universe. Rien que cette nuit j'ai encore du perdre une dizaine d'UT sur l'ensemble de mes machines. Le temps passé et le temps "point de reprise" s'incrémentent sans fin, le % d'avancement ne bouge plus. Je suis obligé d'abandonner ces tâches. Cela me fait des heures et des heures de crunch de perdues  .

Une idée du problème ? Cela arrive à qqun d'autre ? 

[maxymus83]

Bon ben j'ai été faire un tour sur les forums du projet, le problème existe depuis bien longtemps et pour pas mal de monde, et il n'est pas résolu.
Les UTs bloquées cela arrive quelque soit le CPU, le système d'exploit, la version de boinc, etc...
Je trouve qu'il y a quand même un lien entre le nombre d'UT bloquées et les séries d'UT téléchargées. Le mois dernier par exemple, j'ai abandonné des UT mais très peu ... cette semaine c'est la cata 

Je vais donc rester zen et tenter d'atteindre l'objectif des 10M tranquillement 

Le top serait de créer un règle avec boinc task : si "point de reprise" >30min  alors "suspendre la tâche"
Cela permettrait d'éviter de gaspiller des heures de temps CPU.

[Alan St-Pierre]

Moi j'ai un autre type de problème avec ce projet, il m'est tout simplement impossible d'envoyer le résultat de mes unités de travail au serveur, il reste bloqué au statut d'envoi en cours. Des solutions?

[GuL]

Salut Alan,
Combien de tâches essayes-tu de renvoyer d'un coup ? Est-ce que tu peux nous copier la fenêtre des messages au moment où ça essaye de renvoyer stp ?

[[AF>Amis des Lapins] Jean-Luc]

Alan St-Pierre,

En dernier recours, tu peux aussi lire la réponse #93 de cette page :

https://forum.boinc-af.org/index.php/topic,7841.75.html

J'avais eu le même problème sur NumberFields et cette solution a fonctionné.

[GuL]

J'ai eu un problème similaire il n'y a pas longtemps avec pas mal de tâches SETI en stock, suite à une mauvaise connexion internet. J'avais le message suivant et rien ne partait.

4602   SETI@home   15/05/2018 00:32:45   Reporting 253 completed tasks   
4603   SETI@home   15/05/2018 00:32:45   Not requesting tasks: "no new tasks" requested via Manager   
4605   SETI@home   15/05/2018 00:37:06   Scheduler request failed: HTTP internal server error   

J'ai trouvé ceci sur le forum SETI :

5/11/2018 8:28:52 AM | SETI@home | Sending scheduler request: To report completed tasks.
5/11/2018 8:28:52 AM | SETI@home | Reporting 200 completed tasks

Hi there, I suspect your problem is this one and that you should try to set the amount of tasks to report at the same time to a much smaller amount.
You can do that with the <max_tasks_reported>N</max_tasks_reported> option in cc_config.xml

Try to start low, like 4, then work your way up. Remember there's a 5 minute delay between all reports.

<cc_config>
<log_flags>
</log_flags>
<options>
<max_tasks_reported>4</max_tasks_reported>
</options>
</cc_config>

En clair, je renvoyais trop de tâches d'un coup et le serveur les refusait. J'ai utilisé ce que propose Ageless et ça marche.

[JeromeC]

Mais c'est bizarre ça depuis le temps que je boinc je ne me suis jamais posé la question et j'ai toujours vu au plus deux tâches en upload simultané, jamais plus (et ça me va très bien, je vois pas trop l'intérêt d'en avoir plus, elles finissent toujours par partir ), que ce soit sur Mac ou PC (et toutes versions de boinc confondues de mémoire), donc pour en avoir "beaucoup" en upload à la fois ça sous-entend que ce paramètre a déjà été bricolé, non ?

[GuL]

Je ne me souviens pas l'avoir bricolé, d'ailleurs il était de mémoire réglé à 0, mais ce qui est sûr, c'est que cette machine a un fichier cc_config.xml très rempli. Il me semble que c'est apparu quand j'ai exclu le fonctionnement de BOINC en présence de certaines applications (traitement de photos, Matlab,...)

[JeromeC]

Avoir 0 comme valeur dans un cc_config ne veut pas forcément dire "utiliser la valeur par défaut de boinc" (qui, dans mon cas, est clairement "2"), c'est peut être mieux de pas le mettre du tout dans cc_config alors...

<max_tasks_reported>N</max_tasks_reported>
Report at most N tasks per scheduler RPC. Try N=1000 if your computer has lots of tasks to report and is having trouble completing a scheduler RPC.
<ncpus>N</ncpus>

Renvoyer au plus N tâches par ordonnanceur RPC. Essayez N=1000 si votre ordinateur a beaucoup de tâches à renvoyer et a des difficultés à "compléter un planificateur RPC".

[je comprends "terminer un ordre de chargement d'un certain nombre de tâches" dans ce cas]


Concernant les applis que tu as exclus, Boinc te gênait effectivement quand tu lançais les applis en question ?

Pour ma part le principe de "priorité basse des tâches boinc" (tout OS confondu) a toujours très bien fonctionné, avec 90% des projets (*) et du coup l'exclusion est un peu un gadget je trouve = si l'appli a besoin de 100% des ressources, elle les a (sauf si l'OS lui même demande plus de ressources, mais il a en général une priorité supérieure à toute appli standard).

Après le problème qui demeure, c'est la RAM consommée par les tâches boinc, mais en cas de tâche très ramivore il vaut mieux ne pas laisser en mémoire les tâches suspendues (sauf pour les projets sans point de reprise).

(*) il est vrai que certains projets ont parfois tendance à faire des micro-freeze réguliers, mais qui durent très peu de temps, et je pense que ça dépend de la machine / OS

[GuL]

Avoir 0 comme valeur dans un cc_config ne veut pas forcément dire "utiliser la valeur par défaut de boinc" (qui, dans mon cas, est clairement "2"), c'est peut être mieux de pas le mettre du tout dans cc_config alors...

En effet 

Concernant les applis que tu as exclus, Boinc te gênait effectivement quand tu lançais les applis en question ?

Pour ma part le principe de "priorité basse des tâches boinc" (tout OS confondu) a toujours très bien fonctionné, avec 90% des projets (*) et du coup l'exclusion est un peu un gadget je trouve = si l'appli a besoin de 100% des ressources, elle les a (sauf si l'OS lui même demande plus de ressources, mais il a en général une priorité supérieure à toute appli standard).

Oui, le temps de calcul était multiplié par 2 ou 3, même sur un i7 4790K avec un cœur de libre et le GPU désactivé. Le problème, c'est que même si l'autre application est prioritaire, boinc essaye quand même d'accéder au cpu, ce qui nécessite des échanges entre la mémoire cache et la RAM, et donc ralentit l'ensemble. Et comme en plus je chronométrais pour comparer des algorithmes, l'impact était réellement notable, que ce soit sous linux ou sous windows. 

[Alan St-Pierre]

Bon et bien les résultats viennent de partir, il faut croire que mon ordi était tannée de les héberger et les a forcer à aller s'annoncer au serveur. Pourtant je n'ai rien fait, mais la situation s'est débloquée d'un coup. Merci quand même 

[JeromeC]

@Gul : ah, je trouve ça bizarre que boinc puisse autant perturber l'exécution d'une appli (quelle qu'elle soit), tout le principe est justement que boinc n'utilise que des ressources inutilisées (d'où le principe de priorité de process basse)... ou alors tes tâches boinc bouffaient déjà beaucoup de RAM et lancer des applis très consommatrices de RAM résultait en un remplissage total de la RAM et en un swap disque / mémoire massif ? (IO disques frénétiques = très gros ralentissement de tout, ça m'arrive - très rarement - quand mes 16 Go sont pleins )


@Alan : à la bonne heure

[GuL]

@ Alan
Bonne nouvelle !

@Jerome
En fait, pas besoin que la RAM soit pleine, en tout cas ça ne swappait pas. La RAM est au minimum 10 fois plus lente que le cache CPU. Quant au disque, il est 100 fois plus lent que la RAM (enfin ça dépend bien sûr si c'est un disque à plateau ou un SSD).

Donc quand tu as une application gourmande, comme par exemple une appli de traitement de photos raw ou une appli de calcul scientifique hors boinc qui veut accéder au processeur, elle demande la priorité et transfert ses données sur le cache du processeur. Mais comme Boinc essaye de combler les trous d'utilisations, il transfert aussi ses données dans le cache, reléguant les données de l'application prioritaire dans la RAM, qui est beaucoup plus lente. Quand le CPU a à nouveau besoin des données prioritaires, il doit aller les rechercher sur la RAM. Les données font donc des allers-retours entre le cache et la RAM, vu que le cache n'est pas assez grand pour contenir à la fois le calcul prioritaire et Boinc, ce qui ralentit considérablement le calcul.

Je suis d'accord avec toi que dans un monde idéal, le problème ne se poserait pas. Pour la plupart des applications, il n'y a d'ailleurs pas de problème. Pour les applications gourmandes, c'est autre chose. Une alternative à l'exclusion d'application est de dire d'arrêter de calculer si l'utilisation du proc dépasse 25% par exemple.

[JeromeC]

Ah je n'avais pas une vision aussi profonde de la chose ! le cache, le cache !



Quant au % moi j'aime pas brider boinc