World Community Grid - Wir haben ein Team hier!

[Krümel]

Jup, ist bei mir auch so.
Scheinen doch noch nicht fertig zu sein...

 

[Maverick-F1]

Login funktioniert nicht & auch das Forum lädt nicht so wirklich...
Vielleicht läuft's im Oktober ja wieder...

 

[enigmation]

Das IBM-Zeugs scheint sich gut selbst zu beschäftigen:

September 18, 2025

• Forum issues detected.
• Sorry about these problems starting so soon after we came back - but - hopefully Dylan resolved them now.
• It all related to an AutoMaint features of DB2. Likely, database went into one of the scheduled maintenance tasks, MVNForum tried to talk to the database, didn't work, MQ blocked MVNForum and the lack of perms on the queue showed up as this init check failure.

 

[Maverick-F1]

Jetzt kommt beim Aufruf des Forums direkt "System Error" - und der Login rennt in einen Timeout...

 

[Sabroe SMC]

Erst schreiben Sie das alles wieder läuft
September 18, 2025

• Forum issues detected.
• Sorry about these problems starting so soon after we came back - but - hopefully Dylan resolved them now.
• It all related to an AutoMaint features of DB2. Likely, database went into one of the scheduled maintenance tasks, MVNForum tried to talk to the database, didn't work, MQ blocked MVNForum and the lack of perms on the queue showed up as this init check failure.

und nun dies beim Versuch sich einzuloggen...:

System error​

World Community Grid is currently experiencing an unexpected error. Please check Facebook or Twitter for more information.

18. September 2025
Es sind Probleme im Forum aufgetreten. Wir entschuldigen uns dafür, dass diese Probleme so kurz nach unserer Rückkehr erneut aufgetreten sind – aber wir hoffen, dass Dylan sie inzwischen behoben hat.
Die Ursache lag in einer Funktion der automatischen Wartung von DB2. Vermutlich hat die Datenbank einen geplanten Wartungsvorgang gestartet, das MVNForum versuchte daraufhin, auf die Datenbank zuzugreifen, was aber nicht funktionierte. MQ blockierte daraufhin das MVNForum, und die fehlende Berechtigung für die Warteschlange führte zu diesem Fehler bei der Initialisierung.

Systemfehler
Bei World Community Grid ist derzeit ein unerwarteter Fehler aufgetreten. Weitere Informationen finden Sie auf Facebook oder Twitter.

Übersetzt mit Google

 

[gemini8]

Ich hörte gerade, dass (mindestens) ein Rechenkraftler eine neue WCG CPID erhalten hat.
Geht das hier noch jemandem so?

 

[Sabroe SMC]

Team statistics​
Statistics last updated:	8/30/25 23:59:59 (UTC) [608 hour(s) ago]

Naja, ganz obenauf sind die Jungs von WCG noch wirklich nicht. Hier mal die Team Statistics vom Team Planet3DNow

 

[enigmation]

Ich hörte gerade, dass (mindestens) ein Rechenkraftler eine neue WCG CPID erhalten hat.
Geht das hier noch jemandem so?

Du meinst hier?

Home

World Community Grid enables anyone with a computer or Android device to donate their unused computing power to advance cutting-edge scientific research on topics related to health and sustainability.

www.worldcommunitygrid.org

Unter Cross-Project Id finde ich meine übliche CPID, also keine neue.

 

[enigmation]

Jup, ist bei mir auch so.
Scheinen doch noch nicht fertig zu sein...

Ich konnte nun das Device Profiles erfolgreich ändern.

Home

World Community Grid enables anyone with a computer or Android device to donate their unused computing power to advance cutting-edge scientific research on topics related to health and sustainability.

www.worldcommunitygrid.org

Und sie haben ein neues Zieldatum ausgegeben: Ab Montag, 29.9. soll wieder alles laufen!

September 25, 2025

• BOINC scheduler and uploads are projected to be up Monday, September 29th, 2025 after a final weekend sprint to test the new deployment strategy for increased performance, event driven horizontal scaling, and reduced load on the BOINC database.

Na, wir werden sehen ...

 

[gemini8]

Danke für die Rückmeldung.
Die CPID, die auf dem Rechner ankommt, ist verändert.
Aufgefallen ist es in der GridCoin Wallet.
Bei mir ist da alles wie sonst.

 

[Maverick-F1]

Dauert wohl doch noch länger - und auf Jurisica steht auch noch nix Neues...
Mal schauen, ob die im Oktober mal wieder an den Start kommen...

 

[Sabroe SMC]

September 30, 2025

Tech team is working through issues with the WAS container configuration and the BOINC daemon builds on the science cluster.
We are also pinging data centre admis as we don't have the /science filesystem on 1/6 of the science nodes, don't have the ability to add the IP address to the NFS share
Hopefully, not a blocker but does lock that node out of some roles until we can mount the NFS share.


30. September 2025
Das Technikteam arbeitet an Problemen mit der WAS-Container-Konfiguration und den BOINC-Daemon-Builds auf dem Forschungscluster.
Wir haben außerdem Kontakt zu den Rechenzentrum-Administratoren aufgenommen, da auf einem der sechs Forschungscluster-Knoten das Dateisystem `/science` fehlt und wir die IP-Adresse nicht zum NFS-Freigabebereich hinzufügen können.
Hoffentlich ist dies kein größeres Problem, aber bis wir den NFS-Freigabebereich mounten können, kann dieser Knoten einige Funktionen nicht nutzen.

Übersetzt mit Google

Ich würd eher sagen November wird das was, vielleicht!

 

[Krümel]

Ich würd eher sagen November wird das was, vielleicht!

Welches Jahr?

 

[Maverick-F1]

October 2, 2025

• Hosting resolved the issue with our NFS shares in Openstack; scheduler and download path seem to work; we are debugging the new containerized file_upload_handler FCGI worker pool and file_upload_handler integration with Kafka through the librdkafka library.
• We will remove the ACL restrictions that are causing 403 forbidden when users try to contact the scheduler or upload files shortly.
• We are still validating the end-to-end upload path with our local BOINC clients. Once we confirm it, we will open up traffic to the upload servers, start serving the downloads that were available when we shutdown, and we can start turning the BOINC daemons back on.

Mal schaun, ob das wirklich so schnell was wird...
(Noch krieg' ich den genannten 403...)

Edit:
Zumindest kommen die Infos deutlich häufiger...

 

[Sabroe SMC]

October 3, 2025

We are aware of the issue with the scheduler returning "Another scheduler instance is running for this host" and have identified the cause in the config.xml template we adapated for the new containerzied environment. We will fix it once we have confirmed that the new event-driven validation and assmilation pipelines are working correctly.
Uploads are being processed normally, we've confirmed the new architecture for the containerized file_upload_handler pool behind Apache is correctly producing to the per-application Kafka (Redpanda) topics, storing the event and result data in separate queues on the local brokers partition.
As a result, there will be at least one more weekend sprint. Tentatively, we expect to be producing new workunits next week for MCM1, ARP1, and MAM1 beta version 7.07, validations should resume over the weekend, initial releases of batches will be intermittent.

Wir sind uns des Problems mit dem Scheduler bewusst, der "Eine andere Scheduler -Instanz für diesen Host" zurückgibt und die Ursache in der von uns angepassten CONFIC.XML -Vorlage für die neue Container -Umgebung identifiziert hat. Wir werden es beheben, sobald wir bestätigt haben, dass die neuen ereignisgesteuerten Validierungs- und Assmilationspipelines korrekt funktionieren. Uploads werden normal verarbeitet. Wir haben bestätigt, dass die neue Architektur für den Containered File_Upload_Handler-Pool hinter Apache korrekt für die pro-application kafka (redpanda) produziert und die Ereignisse speichert und Daten in separaten Warteschlangen auf der lokalen Broker-Partition ergeben. Infolgedessen wird es mindestens einen weiteren Wochenendsprint geben. Wir erwarten vorläufig, nächste Woche neue Workunits für MCM1-, ARP1- und MAM1 -Beta -Version 7.07 zu produzieren. Validierungen sollten über das Wochenende wieder aufgenommen werden. Erste Veröffentlichungen von Chargen werden intermittierend sein.


AHA. Es soll nächste Woche losgehen.... Hmmm, ob das stimmt?

 

[MagicEye04]

Erinnert mich an Fusionskraftwerke. Die gibt es ja auch bald.

 

[Sabroe SMC]

Na ich glaube schon das WCG in rd. 50 Jahren den Exitus erreicht haben wird

 

[Maverick-F1]

Es tut sich was!:
October 7, 2025

• We have resolved the issue with the BOINC scheduler configuration causing "Another scheduler instance is running for this host". Users should be able to report tasks. We will update as soon as we begin creating new workunits as we are still working to stand up the rest of the BOINC backend architecture.
• Website went down briefly as we brought the scheduler online. We have adjusted the HAProxy configuration, and we will continue to adjust Apache/HAProxy config if we see the website stops responding again.
• Still debugging issues with the new Kafka-based validation workflow that works together with HAProxy routing rules to partition BOINC downloads and uploads by assigning servers equal hex buckets using the https://github.com/BOINC/boinc/wiki/DirHierarchy BOINC expects, and emitting events from the new file_upload_handler we wrote to Kafka so we can batch and respond to them in parallel. This removes the need for multiple round trips to the database for row-wise operations and polling, which are now simply batch applications of state after consuming workunits ready for validation in the relevant Kafka topic for that application. This allows us to perform validation and assimilation in the same process, at least for the projects we run ourselves (MCM1, MAM1, ARP1), and while the Kafka/Redpanda learning curve was significant, we have successfully transitioned to an event-driven in-memory partitioned architecture that should let us keep pace with the upcoming GPU enabled MAM1 application.

Über Nacht ist mein Server zumindest mal seine WUs losgeworden - mal schauen, wann dann endlich auch der Download wieder funktioniert...

 

[Sabroe SMC]

Wir haben das Problem mit der BOINC-Scheduler-Konfiguration behoben, das die Meldung „Eine andere Scheduler-Instanz wird für diesen Host ausgeführt“ verursachte. Benutzer sollten nun Aufgaben melden können. Wir werden aktualisieren, sobald wir mit der Erstellung neuer Arbeitseinheiten beginnen, da wir noch an der Weiterentwicklung der restlichen BOINC-Backend-Architektur arbeiten.
Die Website war kurzzeitig nicht erreichbar, als wir den Scheduler online gestellt haben. Wir haben die HAProxy-Konfiguration angepasst und werden die Apache/HAProxy-Konfiguration weiter anpassen, falls die Website erneut nicht mehr reagiert.
Wir debuggen weiterhin Probleme mit dem neuen Kafka-basierten Validierungsworkflow, der mit HAProxy-Routingregeln zusammenarbeitet, um BOINC-Downloads und -Uploads zu partitionieren. Dazu werden Servern gleiche Hex-Buckets zugewiesen, indem die von BOINC erwartete https://github.com/BOINC/boinc/wiki/DirHierarchy verwendet wird. Außerdem werden Ereignisse vom neuen file_upload_handler, den wir für Kafka geschrieben haben, ausgegeben, damit wir sie bündeln und parallel darauf reagieren können. Dadurch entfallen mehrere Roundtrips zur Datenbank für zeilenweise Operationen und Polling. Diese sind nun lediglich Batch-Anwendungen des Status nach dem Verbrauch von Workunits, die zur Validierung im entsprechenden Kafka-Thema für diese Anwendung bereitstehen. Dies ermöglicht uns, Validierung und Assimilation im selben Prozess durchzuführen, zumindest für die Projekte, die wir selbst betreiben (MCM1, MAM1, ARP1). Und obwohl die Lernkurve für Kafka/Redpanda beträchtlich war, sind wir erfolgreich auf eine ereignisgesteuerte, partitionierte In-Memory-Architektur umgestiegen, die es uns ermöglichen sollte, mit der kommenden GPU-fähigen MAM1-Anwendung Schritt zu halten.

Translation by Google

 

[Sabroe SMC]

October 15, 2025

• Testing the validators right now, been a lot of iterations on these.
• As soon as the validator works, we will deploy across the six partitions and clear the backlog. Then we can check the transitioner interaction. If that is all good, we can finally start sending new work.
• Going to finalize object storage for the archive - instead of previous tape backup.

15. Oktober 2025
Wir testen gerade die Validatoren. Es gab viele Iterationen.
Sobald der Validator funktioniert, werden wir ihn auf den sechs Partitionen bereitstellen und den Rückstand abarbeiten. Anschließend können wir die Interaktion mit dem Transitor überprüfen. Wenn alles gut läuft, können wir endlich mit der Übermittlung neuer Arbeiten beginnen.
Wir werden den Objektspeicher für das Archiv fertigstellen – anstelle der bisherigen Bandsicherung.

Es dauert also noch ein Weilchen....

 

[Maverick-F1]

Es geht wohl (tatsächlich) langsam wieder los - es sollen wohl schon die ersten kleinen (wenigen) Test-WUs verschickt:

October 18, 2025

• We are sending small batches of workunits out starting tonight with batch IDs in the range 9999900+ for MCM1 to test the new distributed partition-aware batch upserting app-specific create_work daemons. The few volunteers who get these workunits before we start releasing larger batches as we gain confidence that the new system is working as expected may notice these workunits have a much smaller number of signatures and run much faster than normal. These are still meaningful workunits, but key parameters such as number of signatures to test per workunit were reduced so we could get feedback quckly.
• Similar to ARP1, we have moved all workunit templating and preparation to WCG servers for MCM1. We did this for the MAM1 beta (beta30) already, but we were able to move the rendering of workunit templates per batch into the create_work daemon C++ code directly, where it consumes a protobuf schema from Kafka/Redpanda's schema registry that it then hydrates to produce all workunits for the batch according to the desired parameters it consumes from the "plan" topic via Kafka. Hence, "app-specific" above. Then, it updates the BOINC database in bulk instead of calling BOINC's create_work() function. Metadata is local, partitioned, replicated in Kafka for durability, each batch writes files to that nodes' 1/6th of the buckets from the BOINC dir_hier fanout directory and commits 1/6th of the batch records to the database in non-overlapping ranges per 10k workunits per batch.
• The new validators are working and deployed. In our new distributed, partitioned approach, validators process workunits local to their host ONLY, uploads are partitioned according to the fanout directory assigned by BOINC, routed to the correct backend node by HAProxy corresponding to the BOINC fanout buckets. We split the buckets between nodes, instead of using them to fanout across the filesystem and avoid massive numbers of files in a single BOINC upload path, we fan out across the cluster and read/write these buckets in tmpfs so Apache serves downloads and accepts uploads in-memory, validators read in-memory, Kafka/Redpanda gets a copy of uploads into a disk-persisted, replicated topic for durability so if a node goes down and we lose the in-memory cache of downloads and uploads, we can replay and recover
• By subscribing to a Kafka topic containing the count of uploads, a reduction on upload events emitted to Kafka topics from the new file_upload_handlers for only the local buckets of that partition, file locations pertaining to a pair of workunits, and emits success or failure to another queue for downstream "assimilation". We have written and are testing a batch applier that collects successful validation events on each partition, and batch updates the BOINC database so that the transitioner and scheduler can work together to evaluate the state of those workunits. Once we are confident the batch updates work as expected from the applier, users should start seeing workunits pending validation clear to valid.
• We are not running file_deleter or db_purge at the moment, they need to be rearchitected to match the new setup, or at minimum assessed to make sure it makes sense to start them unchanged. We have no concerns about running out of space in the database or on disk at the moment, only making mistakes, so we will get around to assessing what if anything needs to change about file_deleter and db_purge soon but not now. Likely, they will also take advantage of per-workunit event data from Redpanda/Kafka instead of just talking to the BOINC database and operate on local partitions across the cluster. But as we are producing events for every workunit's full lifecycle to Kafka topics we have a level of visibility and control we were never able to achieve with the legacy system, and we were able to set up prometheus node_exporter, tap into docker stats endpoints per node across the cluster, and likewise for Redpanda/Kafka with the helpful https://github.com/redpanda-data/observability repo to get a Grafana dashboard going that will let us do many things, such as serve up server status pages, and improve the stats pages.

 

[Krümel]

Oh Wunder, gerade sind 24 MCM eingetrudelt.

 

[Maverick-F1]

Bei mir sogar ~ 180!
Des is' wie Weihnachten!

 

[olsen_gg]

Na dann: Gedicht aufsagen und sich freuen!

 

[olsen_gg]

Hier immer wieder:

21.10.2025 18:05:39 | World Community Grid | update requested by user
21.10.2025 18:05:42 | World Community Grid | Sending scheduler request: Requested by user.
21.10.2025 18:05:42 | World Community Grid | Not requesting tasks: don't need (CPU: ; NVIDIA GPU: ; Intel GPU: )