[WCG] World Community Grid (multi-projets)

[fzs600]

Ha non pas encore  y a des petits  qui traînent dans le hall. 

[modesti]

3.5" Madame, 3.5"

Oups, au temps pour moi. J'ai dû confondre avec le format des disquettes du traitement de texte Amstrad

[JeromeC]

18 octobre 2025

• Nous envoyons dès ce soir de petits lots d'unités de travail avec des identifiants de lot compris entre 9999900+ pour MCM1 afin de tester les nouveaux démons create_work spécifiques à l'application, qui permettent la mise à jour et la création de lots distribués tenant compte des partitions. Les quelques volontaires qui recevront ces unités de travail avant que nous commencions à publier des lots plus importants, lorsque nous serons certains que le nouveau système fonctionne comme prévu, remarqueront peut-être que ces unités de travail comportent un nombre de signatures beaucoup plus faible et s'exécutent beaucoup plus rapidement que la normale. Il s'agit toujours d'unités de travail significatives, mais les paramètres clés tels que le nombre de signatures à tester par unité de travail ont été réduits afin que nous puissions obtenir rapidement des commentaires.


• Comme pour ARP1, nous avons transféré tous les modèles et la préparation des unités de travail vers les serveurs WCG pour MCM1. Nous l'avions déjà fait pour la version bêta de MAM1 (beta30), mais nous avons pu transférer le rendu des modèles d'unités de travail par lot directement dans le code C++ du démon create_work, où il utilise un schéma protobuf provenant du registre de schémas de Kafka/Redpanda, qu'il hydrate ensuite pour produire toutes les unités de travail du lot selon les paramètres souhaités qu'il utilise à partir du sujet « plan » via Kafka. D'où le terme « spécifique à l'application » ci-dessus. Ensuite, il met à jour la base de données BOINC en bloc au lieu d'appeler la fonction create_work() de BOINC. Les métadonnées sont locales, partitionnées, répliquées dans Kafka pour plus de durabilité, chaque lot écrit des fichiers dans 1/6e des compartiments de ce nœud à partir du répertoire fanout dir_hier de BOINC et valide 1/6e des enregistrements du lot dans la base de données dans des plages non superposées par 10 000 unités de travail par lot.


• Les nouveaux validateurs fonctionnent et sont déployés. Dans notre nouvelle approche distribuée et partitionnée, les validateurs traitent UNIQUEMENT les unités de travail locales à leur hôte, les téléchargements sont partitionnés selon le répertoire de diffusion attribué par BOINC, acheminés vers le nœud backend correct par HAProxy correspondant aux compartiments de diffusion BOINC. Nous répartissons les compartiments entre les nœuds, au lieu de les utiliser pour les répartir sur le système de fichiers et éviter un nombre massif de fichiers dans un seul chemin de téléchargement BOINC. Nous les répartissons sur le cluster et lisons/écrivons ces compartiments dans tmpfs afin qu'Apache serve les téléchargements et accepte les téléchargements en mémoire, que les validateurs lisent en mémoire, Kafka/Redpanda obtiennent une copie des téléchargements dans un sujet répliqué et persistant sur le disque pour plus de durabilité. Ainsi, si un nœud tombe en panne et que nous perdons le cache en mémoire des téléchargements et des chargements, nous pouvons les rejouer et les récupérer.


• En s'abonnant à un sujet Kafka contenant le nombre de téléchargements, une réduction des événements de téléchargement émis vers les sujets Kafka à partir des nouveaux file_upload_handlers uniquement pour les compartiments locaux de cette partition, les emplacements de fichiers appartenant à une paire d'unités de travail, et émet la réussite ou l'échec vers une autre file d'attente pour « assimilation » en aval. Nous avons écrit et testons actuellement un applicateur par lots qui collecte les événements de validation réussis sur chaque partition et met à jour par lots la base de données BOINC afin que le transitionneur et le planificateur puissent travailler ensemble pour évaluer l'état de ces unités de travail. Une fois que nous sommes certains que les mises à jour par lots fonctionnent comme prévu depuis l'applicateur, les utilisateurs devraient commencer à voir les unités de travail en attente de validation passer à l'état « valide ».


• Nous n'utilisons pas file_deleter ni db_purge pour le moment, car ils doivent être repensés pour s'adapter à la nouvelle configuration, ou au minimum évalués pour s'assurer qu'il est judicieux de les lancer sans modification. Nous ne craignons pas pour l'instant de manquer d'espace dans la base de données ou sur le disque, mais seulement de commettre des erreurs. Nous évaluerons donc bientôt, mais pas maintenant, si des modifications doivent être apportées à file_deleter et db_purge. Il est probable qu'ils exploiteront également les données d'événements par unité de travail provenant de Redpanda/Kafka au lieu de se contenter de communiquer avec la base de données BOINC et d'opérer sur des partitions locales à travers le cluster. Mais comme nous produisons des événements pour le cycle de vie complet de chaque unité de travail vers les sujets Kafka, nous disposons d'un niveau de visibilité et de contrôle que nous n'avons jamais pu atteindre avec l'ancien système, et nous avons pu configurer prometheus node_exporter, exploiter les points de terminaison des statistiques Docker par nœud à travers le cluster, et de même pour Redpanda/ Kafka avec l'aide du dépôt https://github.com/redpanda-data/observability afin de mettre en place un tableau de bord Grafana qui nous permettra de faire beaucoup de choses, comme afficher les pages d'état du serveur et améliorer les pages de statistiques.

21 octobre 2025

• Enfin, des tests de résistance plutôt que des tests de conformité.


• Envoi d'un lot de 100 000 unités de travail (exécution rapide, taille réduite au cas où quelque chose planterait).


• Merci pour votre patience et votre soutien continu.

[modesti]

Le résumé en trois lignes me va très bien

Et sinon, en allant dans mon compte, vu l'arrivée de l'appli Mapping Arthritis Markers (MAP).
En revanche, malgré mon choix de faire du bêta et la demande de m'inscrire aux nouvelles applis lorsqu'elles arrivent, ben, l'appli n'était pas cochée. Peut-être parce que j'avais décoché MCM ?

[JeromeC]

De toutes façons vu les monstres qui ont toujours fait (et referont) du WCG c'est pas 100k tâches qui vont nourrir leur homme...

[[CSF] Christian Carquillat]

J'ai peu fermé les vannes sur Asteroids, ça me prend du MCM
Jusqu'au choix du prochain sprint (avant ou après ma nuit, bonne question)

[JeromeC]

Ni avant ni après, c'est à minuit

[JeromeC]

24 octobre 2025

• Nous avons suspendu les téléchargements et la publication des lots de test pendant que nous travaillons sur le problème de débit de validation.


• Nous pensons avoir identifié la cause principale du faible taux de validation des lots de test MCM1, et nous enverrons quelques lots de test supplémentaires pour confirmer que la correction fonctionne.


• Si cette correction est définitive et que nous constatons le taux de validation attendu pour les paires de téléchargements MCM1 pour les nouveaux lots, nous réutiliserons le consommateur Kafka sur les événements de téléchargement déclenchés pour les lots de test reçus plus tôt dans la semaine, ce qui devrait permettre au nouvel assimilateur de lots de traiter ces validations et d'attribuer des crédits de manière idempotente.


• Si tout se passe bien, nous programmerons la reprise des lots MCM1 réguliers à la place des lots de test.


• Comme l'ont fait remarquer les bénévoles, nous n'avons pas encore réconcilié les téléchargements des résultats MCM1 réguliers soumis avant que nous commencions à envoyer les lots de test et avant la migration, mais nous disposons de ces fichiers et nous pourrons le faire dans le cadre d'une mise à jour par lots une fois que le chemin d'accès aux nouvelles unités de travail fonctionnera comme décrit ci-dessus.


• Naturellement, nous ne reprendrons l'ARP et le MAM qu'une fois ces problèmes entièrement résolus.

28 octobre 2025

• Nous avons corrigé les principaux problèmes de débit de validation avec le nouveau flux de travail basé sur Kafka et avons retraité les téléchargements effectués à partir du moment où nous avons commencé à envoyer des lots de test. Nous examinons actuellement les sujets Kafka et la base de données BOINC afin de déterminer si les rapports des bénévoles concernant les résultats d'une unité de travail test téléchargée mais non validée/assimilée lors du retraitement constituent un autre bug à corriger et, le cas échéant, si celui-ci est suffisamment grave pour bloquer la distribution régulière des lots MCM1_024% jusqu'à sa résolution.


• En examinant la mise en œuvre du transitioner (que nous avions l'intention de lancer hier pour commencer à déclencher les renvois des lots de test), nous avons constaté que le nouveau paradigme de stockage des détails de configuration nécessaires pour remplir les renvois dans le tableau des résultats devait être intégré dans les fonctions clés. Nous testons actuellement ces modifications relativement mineures du transitioner.


• Notre plan consiste à déployer le transitioner mis à jour, à vérifier que les renvois fonctionnent, à vérifier qu'il expire les unités de travail expirées, et en fonction de cela et de l'examen des « validations manquées » mentionnées ci-dessus, nous pourrions alors être prêts à reprendre les lots MCM1 dans la fourchette normale.


• En ce qui concerne les téléchargements qui couvrent la période d'indisponibilité pour la migration, nous procéderons à la validation et à l'attribution des crédits pour ces unités de travail dès que le chemin de production pour MCM1 décrit ci-dessus sera opérationnel.


• Nous devrions pouvoir utiliser les nouveaux composants pour ce faire, après avoir parcouru les systèmes de fichiers où se trouvent ces téléchargements, vérifié la liste qui doit être validée et créditée dans la base de données, et suivi un chemin de « retraitement » similaire qui a bien fonctionné pour réessayer la validation et le crédit des lots MCM1 de test.


• Ensuite, nous commencerons à tester beta30/MAM1 et ARP1 à l'aide du nouveau système, ce qui devrait progresser beaucoup plus rapidement maintenant que nous avons mis au point la logique avec MCM1.


• Les mises à jour des stats reprendront dès que le flux de travail MCM1 sera stable, ce qui inclura l'exportation quotidienne vers https://download.worldcommunitygrid.org/boinc/stats/

Je crois que j'ai enfin tout compris : en fait ils font des test, afin de préparer des tests, comme ça quand ils ont fini leurs tests, ils peuvent passer aux tests, et comme ça, dès que les tests sont prêts, hop on peut commencer les tests. 

Ca me rappelle un film : neverending stoooryyyyyy...

[[CSF] Christian Carquillat]

Et t'as même pas parlé des tests en cours qui attestent des tests qu'on déteste, c'est bâclé comme réponse 
Tu peux pas test 

[JeromeC]

Je teste si je veux !!

[JeromeC]

En parcourant en diagonale les deux dernières pages d'un énorme topic sur le fofo de WCG j'ai cru comprendre que

- on peut avoir des tâches qu'en bricolant le fichier host de chaque bécane (j'ai pas les détails, juste quelqu'un qui en parle, pas eu le temps ni l'envie de remonter tout ce topic)
- les statistiques ne sont plus générées correctement, le compteur de crédit et de tâches est bancale (du moins sur le site WCG)

[[CSF] Christian Carquillat]

J'ai des WU sans jamais avoir bricolé ce fichier hosts
Il me semble qu'il fallait le bidouiller aussi pour Rosetta, mais s'il faut retenir toutes les manips avec ma panoplie de bécanes, je ne m'en sortirai pas

[JeromeC]

Ah alors que j'avais rouvert les vannes WCG il y a plusieurs semaines sur le mac je ne me souvenais plus que y'a longtemps j'avais viré MCM de mon profil d'unité car j'en avais raz la casquette de MCM... là j'ai vu qu'ils ont ajouté un projet pour l'arthrite donc je l'ai coché (mais a priori y'a que du MCM) mais j'ai quand même pas remis MCM, faut pas déconner.

Advienne que pourra

[PhilTheNet]

Server error : Feeder not running

 

[Antares]

J'ai l'impression qu'ils "ferment" la boutique le WE...

[JeromeC]

11 novembre 2025

• La maintenance de la base de données effectuée vendredi et samedi s'est déroulée sans problème. Nous avons résolu un problème avec les scripts de sauvegarde, augmenté efficacement la mémoire utilisée pour traiter les requêtes de la base de données et ajouté de nouveaux index. Nous espérons que la base de données BOINC fonctionnera mieux à l'avenir.


• Cependant, le disque reste plus lent que lors des premiers tests de performance effectués lors de la mise en place de la base de données. Nous allons surveiller et contacter l'hébergeur pour voir si l'extension du groupe de placement Ceph (qui a provoqué le blocage de ce disque particulier lorsque le groupe de placement héberge la table des résultats) est restée bloquée dans un état de « peering ». Nous avons été informés que nous devrions nous attendre à un ralentissement temporaire et éventuellement intermittent des E/S pendant cette fenêtre de maintenance Ceph. Si nous pouvons obtenir des disques plus rapides pour la base de données BOINC (ce qui nécessiterait de restaurer la base de données sur un nouveau volume comme nous l'avons fait pour la migration), nous envisagerons une fenêtre de maintenance. Pour l'instant, nous sommes optimistes quant au fait que les problèmes révélés dans le nouveau système par les requêtes de base de données bloquées et les plantages de base de données peuvent tous être résolus avec des correctifs pour les nouveaux démons BOINC, et que les performances actuelles seront suffisantes.


• Comme mentionné, cet événement a permis d'identifier plusieurs problèmes avec les nouveaux démons BOINC.


• La création de l'unité de travail MCM1 se poursuit dans le sujet Kafka même si la base de données est hors service. Le démon mcm1_create_work pour sa partition Kafka sur science01...science06 tente de valider sa partie du lot, mais comme la base de données n'est pas disponible, il ne fait rien. Il valide toutefois son décalage/pointeur dans le sujet du plan de lot et passe à la consommation du plan de lot suivant. Cela signifie que toutes les 10 à 15 minutes pendant que la base de données est hors service, un lot est effectivement ignoré. Nous avons réussi à corriger ce problème et avons redémarré la création de lots MCM1 vers 17 h 00 EST, le 10 novembre 2025.


• Nous pensons avoir enfin trouvé une solution au problème de validation en attente. Cela nécessite quelques modifications non négligeables dans l'assimilateur de lots MCM1, un connecteur Kafka déployé sur le nœud de base de données BOINC et des modifications du code de transition.


• L'approvisionnement en unités de travail pourrait rester artificiellement faible pendant que nous déployons les nouvelles versions de l'assimilateur de lots et surveillons la transition -> la consommation d'événements Kafka et l'interaction avec le tableau des résultats.


• Nous avons réussi à résoudre le problème lié au fait que les préférences informatiques n'étaient pas mises à jour du site web vers le client BOINC et vice versa. En général, lorsque la base de données BOINC tombe en panne, il en va de même pour l'écouteur d'événements qui traite ces messages sur le serveur web.


• Nous travaillons toujours à résoudre le retard accumulé dans la validation pendant les vacances. Le tableau des résultats ayant été bloqué pendant la maintenance de Ceph, nous avons conçu une solution « trust the filesystem » (faire confiance au système de fichiers) et nous espérons que ce problème sera résolu cette semaine.


• Il était initialement prévu que MAM1 reprenne dans la version bêta 30 la semaine dernière, afin de vérifier si la version 7.07 planifie correctement le travail et respecte --nthreads, ce qui constitue un obstacle à la promotion de l'application bêta en production. En fonction du taux d'erreur et du comportement des clients BOINC, nous envisagerions alors les chemins d'accès au code stable pour les premiers lots de production. Compte tenu de notre contrôle accru sur les paramètres des lots grâce au nouveau sujet Kafka qui utilise un schéma protobuf pour remplir les entrées de la table des unités de travail et des résultats, nous avons l'intention d'exécuter le travail en production sur Linux dès que l'application beta30 sera stable avec un taux d'erreur inférieur à MCM1, à l'exception de la dépendance GLIBC, qui est généralement la seule erreur répétée que nous observons chez les clients sur le chemin d'accès au code LibTorch actuel. Nous nous appuierons ensuite sur l'itération de l'application beta30 vers les versions 7.08 et 7.09 pour obtenir la prise en charge du GPU et de Windows, ainsi que Parquet IO pour les entrées et les résultats téléchargés.

21 novembre 2025

• Nous testons actuellement les modifications nécessaires au planificateur et au chargeur afin de résoudre les problèmes liés aux entrées « os_name » et « os_version » corrompues/tronquées, telles que « W »/« W » pour certains hôtes, comme signalé par les utilisateurs sur les forums, et afin de résoudre les fréquents blocages du chargeur où le message « Aucune tâche disponible pour la plateforme » est logiquement incorrect selon hr_class, alors que les tâches qui remplissent le segment de mémoire partagée du feeder restent non attribuées par les passes du planificateur et qu'une intervention manuelle est nécessaire pour que le travail reprenne.


• Les passes des résultats téléchargés qui n'ont pas été crédités par le nouveau système commenceront la semaine prochaine, afin de combler les crédits manquants. Nous avons effectué des essais pour vérifier l'exactitude du système. Par mesure de précaution, nous exécuterons le programme en plusieurs passes, en commençant par les téléchargements les plus anciens, jusqu'aux plus récents.


• Des bénévoles ont signalé que l'API affiche parfois un état invalide pour plusieurs résultats, alors qu'un seul résultat est marqué comme valide, ce qui devrait être impossible. Une enquête préliminaire indique que la nouvelle procédure d'assimilation MCM1 interagit avec le transitioner. La nouvelle procédure d'assimilation MCM1 sert à valider et à créditer tous les résultats en cours pour une unité de travail dès qu'elle a consommé une paire/un quorum de fichiers, qu'il s'agisse des résultats originaux 0 et 1 ou des renvois 2 et plus, qui ont passé la validation. C'est là que nous espérons trouver une explication.

C'est quand même dingue qu'ils rencontrent une telle quantité de problèmes, on dirait qu'ils ont redéveloppé tout boinc from scratch en plus de leur propre projet...