Guessing not UTC!

In reply to Grumpy Swede's message of 15 Jan 2026:

In reply to Hadrian's message of 15 Jan 2026:

Far be it from me to complain but I notice that my recorded contributions to every WCG project have doubled.

That is a known issue. When the WCG system comes back, you can read about it, in this WCG forum thread:
My Contributions totals have DOUBLED

Seems to be back to normal again.

It could be his TZ, or UTC. Big difference.....

Or some TZ only reachable by a TARDIS.

I'm feeling faint - earlier today I had a "new" task, or at least new to me. Also it ran to some sort of completion and is awaiting verification

In reply to robsmith's message of 19 Jan 2026:

I'm feeling faint - earlier today I had a "new" task, or at least new to me. Also it ran to some sort of completion and is awaiting verification

I bet it was a resend _2 or higher, and not a "new" _0 or _1.

I did send a mail to Igor and the support mail. Just in case they haven't noticed that no new work has been sent out, since the feeder came back. I didn't want to bother them during the weekend.

I also got a reply from Igor Jurisica. They are aware of the problem, and Dylan is working on it now. An update is coming from the team.

Well WCG has been acting like they want to be a Project again. Playing with BETA apps and having Tasks available to their general volunteers. Why is it that Stat's and Credit has not been publicly posted for 143 Days ?

Last update user XML 2025-08-30 00:23:20 UTC (143 days 01:46:46 old)
Last update host XML 2025-08-29 00:23:27 UTC (144 days 01:46:39 old)
Last update team XML 2025-08-30 00:23:20 UTC (143 days 01:46:46 old)

Respectfully
Bill Freauff
Dallas TX

---

In October 1969 I took an oath to support and defend the Constitution of the United States against all enemies, foreign and domestic;
There was no expiration date.

Another thing to check out: Newbies with 3 day target

In reply to Grumpy Swede's message of 20 Jan 2026:

Another thing to check out: Newbies with 3 day target

I guess that will favour those with faster machines.

Hi!
Latest news/update from Jurisica:

January 20, 2026
We have chenged the batch plan to have a shorter turnaround, most systems are easily computing within that time frame, and the notion of a "deadline" is significantly different now with the new validators where we greedily try to validate 2 results as soon as we have 2, but use the additional results if we have more than 2, and then assign everybody who is currently processing a result credit and call the workunit done.

The point of the new deadlines is to get work done faster, so the two wingmen receiving results _0 and _1 get 3 days, then the transitioner might notice one or both haven't reported, and whoever downloads the resend _2 workunit gets 3 days to be the wingman, and so on every 3 days until we hit "maxError" (5), "maxCreatedForAnyReason" (10), "maxReturnedSuccessfully" (7). We don't want to keep sending workunits that are just errors no matter who gets them, if we've created it 10 times and someone has the _9 result something is wrong so stop, and if we have 7 results that we in theory could validate and credit already then something is wrong as we should be done after 2, which is what the new system emphasizes, or done after 3 assuming a wingman we thought was going to timeout actually pulls through sometime just after the deadline.

A shorter deadline will help with resends finishing off workunits faster, especially once we are running MAM1 and MCM2 (and ARP1) that is going to make a big difference because instead of random searches, we are going to be doing targeted searches based on best results from the previous round. The faster we have results for the same set of parameters the faster we explore the search space. Resends will use the same delay bound as the workunit was created with, 3 days. The transitioner will refer to the record created in the database for the workunit, so indirectly it references the same parameter from the batch plan published to Redpanda.

Regarding credit, we did not convey that part correctly. The IN_PROGRESS results and late uploads after deadline are not getting credit. The first pair above quorum (2), get credit, and so do any additional results that get uploaded and reported before the validator gets around to retrying the "eligible" workunit pool in chunks and happens to get to this set of results, ending the workunit and expiring any wingmen who were processing results that are not yet reported.

So it is not "everybody who is currently processing a result gets credit", it is in fact "everybody who has already processed and reported a result, before the validator-assimilator daemon checked and found at least 2 SUCCESS results and effectively enforced the deadline".

Hans S.

All downloads now getting transient http error.

(This must be some new meaning of the word, "transient" I wasn't previously aware of.)

Edit: They were transient, most now cleared. There were a whole bunch of png and other files still downloading after the tasks started running. I should have a look and see if I can work out what they were about.

Wcg is down, can't load any threads🤔

And now it is back!! 👍

Wellllllllll....................
Despite the statement made a day or so back the validators are still underperforming - I have about 400 tasks awaiting validation, some of them dating back to August last year. In the case of those very slow to validate there would appear to be sufficient results back and the validators are simply ignoring such data. I would suggest that a validation run be forced, starting with the oldest outstanding result pairs so these will drop out of the pending list and their status correctly marked (error/success/whatever).

I have 2550 and growing awaiting validation

New Update on the Operational Status page.

January 23, 2026

Issues with file_upload_handler on partitions 4, 5, and 6 resolves transient HTTP upload errors - this error generally reflects the file_upload_handler pool of Docker containers that Apache dispatches upload POST requests being in a bad state. As with the validators, assimilators, create_work daemons, file_deleter, db_purge - we will get the file_upload_handler out of a Docker container, after we fix the more pressing MCM1 validation backlog.

MCM1 validation issue resolution may require BOINC database outage - we have concluded that freezing tables by taking the BOINC backend components and database offline to operate on a frozen copy of the key tables in the database would be the fastest and most surefire way to get the backlog validated. From each of the six servers we have referred to as "partitions" that own specific fanout buckets/non-overlapping ranges of workunits, we can assess the validation state of all uploads received by that partition independently against a copy of the result table, work out the exact upserts that will be required to idempotently set the correct state and if the workunit has not already been validated calculate and assign credit to volunteers, and then finally reconcile all six partitions patches and page the upsert against the "offline" (on the network) BOINC database to come back up in a fully resolved state.

"MCM1 validation issue resolution may require BOINC database outage"

Uhh...can you ask what amount of time they're talking about? Hours, days, weeks, months, seasons?

In reply to bill's message of 24 Jan 2026:

"MCM1 validation issue resolution may require BOINC database outage"

Uhh...can you ask what amount of time they're talking about? Hours, days, weeks, months, seasons?

That's impossible to say. However you should read this recent post by Dylan, on the WCG forum. It explains a lot of what's going on now: https://www.worldcommunitygrid.org/forums/wcg/viewthread_thread,47663_offset,200#709152

After a couple of days of smooth running uploads are now having a snooze in the corner.

I have been getting stuff like this for a coupla daze.

Sun 25 Jan 2026 03:36:30 PM EST | World Community Grid | Started upload of MCM1_0246060_3767_1_r961623094_0
Sun 25 Jan 2026 03:36:30 PM EST | World Community Grid | Started upload of MCM1_0246061_8613_1_r491302081_0
Sun 25 Jan 2026 03:36:32 PM EST | World Community Grid | Temporarily failed upload of MCM1_0246060_3767_1_r961623094_0: transient HTTP error
Sun 25 Jan 2026 03:36:32 PM EST | World Community Grid | Backing off 04:55:17 on upload of MCM1_0246060_3767_1_r961623094_0
Sun 25 Jan 2026 03:36:32 PM EST | World Community Grid | Temporarily failed upload of MCM1_0246061_8613_1_r491302081_0: transient HTTP error
Sun 25 Jan 2026 03:36:32 PM EST | World Community Grid | Backing off 04:59:36 on upload of MCM1_0246061_8613_1_r491302081_0

---

In reply to Jean-David's message of 25 Jan 2026:

I have been getting stuff like this for a coupla daze.

Sun 25 Jan 2026 03:36:30 PM EST | World Community Grid | Started upload of MCM1_0246060_3767_1_r961623094_0
Sun 25 Jan 2026 03:36:30 PM EST | World Community Grid | Started upload of MCM1_0246061_8613_1_r491302081_0
Sun 25 Jan 2026 03:36:32 PM EST | World Community Grid | Temporarily failed upload of MCM1_0246060_3767_1_r961623094_0: transient HTTP error
Sun 25 Jan 2026 03:36:32 PM EST | World Community Grid | Backing off 04:55:17 on upload of MCM1_0246060_3767_1_r961623094_0
Sun 25 Jan 2026 03:36:32 PM EST | World Community Grid | Temporarily failed upload of MCM1_0246061_8613_1_r491302081_0: transient HTTP error
Sun 25 Jan 2026 03:36:32 PM EST | World Community Grid | Backing off 04:59:36 on upload of MCM1_0246061_8613_1_r491302081_0

https://www.worldcommunitygrid.org/forums/wcg/viewthread_thread,47663_offset,200#709152

Progress! Uploads cleared. However no tasks available for any of my selected projects. (all of them.)