It would appear as though WCG is down, again.

I've not been able to get new WUs for a bit, uploads are failing, their feeder service seems to be down, reporting WUs doesn't seem to remove them from my machines, and their forums are a 503.

The server status page is a poor version of this. No idea why they keep it there at all. no idea why some projects don't have an honest queue displayed. What are they hiding?

Can't comment on other projects, especially those I have had little involvement with but CPDN only updates the server status page every couple of hours which means small batches of work can be gone before they show up on the page.

This is common - the updating frequency is low on other projects too. Rosetta is odd, since the updating time of server status and the updating time of the main page are different, so one is usually ahead of the other, but not always the same one.

  15:37:36 STEP 2952 H=2952:00 +CPU= 20.358

Jean-David wrote:

I do not understand how that applies on the current task my machine is working on.
If the one marked "Didn't need" ran before mine, why send it to me at all?

This doesn't apply to your tasks. I'm referring to a task that was never sent to anyone. It never ran.

I think it does, it seems to be the exact situation as yours. These tasks expired while still in queue waiting to be sent out. I'm trying to remember if I've seen a similar thing at MilkyWay last year when they had validation issues and very excessive queue of tasks was getting generated.

What is shrss?

The message is written by https://github.com/BOINC/boinc/blob/master/client/app_control.cpp#L1551, and seems to be controlled by

old_time = atp->checkpoint_cpu_time;  // the saved time of the last checkpoint
if (old_time != atp->checkpoint_cpu_time) {  // if they are different ...

so you shouldn't see two messages with the same time.

Edit - OK, so 1 second apart is indeed 'different'. But I can never unravel David Anderson's spaghetti code much beyond that.

I think the wisest thing is to turn off that log flag (it'll spam the system journal in no time), and stop worrying about it.

22-Dec-2022 03:24:54 [climateprediction.net] Starting task oifs_43r3_ps_0497_1993050100_123_962_12179141_0
22-Dec-2022 03:24:54 [climateprediction.net] [cpu_sched] Starting task oifs_43r3_ps_0497_1993050100_123_962_12179141_0 using oif
s_43r3_ps version 105 in slot 6
22-Dec-2022 03:25:00 [climateprediction.net] [checkpoint] result oifs_43r3_ps_0497_1993050100_123_962_12179141_0 checkpointed
22-Dec-2022 03:25:01 [climateprediction.net] [checkpoint] result oifs_43r3_ps_0497_1993050100_123_962_12179141_0 checkpointed
22-Dec-2022 03:25:03 [climateprediction.net] [checkpoint] result oifs_43r3_ps_0497_1993050100_123_962_12179141_0 checkpointed
22-Dec-2022 03:25:04 [climateprediction.net] [checkpoint] result oifs_43r3_ps_0497_1993050100_123_962_12179141_0 checkpointed

22-Dec-2022 03:36:40 [climateprediction.net] [checkpoint] result oifs_43r3_ps_0497_1993050100_123_962_12179141_0 checkpointed
22-Dec-2022 03:36:41 [climateprediction.net] [checkpoint] result oifs_43r3_ps_0497_1993050100_123_962_12179141_0 checkpointed
22-Dec-2022 03:37:00 [World Community Grid] [checkpoint] result MCM1_0193439_9713_3 checkpointed
22-Dec-2022 03:37:04 [climateprediction.net] [checkpoint] result oifs_43r3_ps_0497_1993050100_123_962_12179141_0 checkpointed
22-Dec-2022 03:37:05 [climateprediction.net] [checkpoint] result oifs_43r3_ps_0497_1993050100_123_962_12179141_0 checkpointed

Looks like file names may be slightly different in Red Hat for the record the ca-bundle.crt on Ubuntu is by default in /var/lib/boinc-client/

Question: How do people feel about a monthly upload of around 193Mb?

There should be some way to better spread these small test batches (if that’s what this micro-batch was) around so that they don’t all get sucked into this kind of black hole machine. Otherwise this will become more and more of a problem as processors get ever larger numbers of cores.

I agree. Usually this is done via the testing site. I have I suspect the slowest machine on there and on that these tasks would take about 20 days. The machine I use for testing site runs 24/7 which the machine with the tasks clearly doesn't as it is a lot faster yet still takes 65 days to turn tasks around..

I don't know why these were sent out on the main site rather than testing. The other option if there is a good reason for using the main site for them would be to send out say 100 instead of 15 which would hopefully get enough data back quickly.

I vaguely remember discussion of Rosetta eating up l3 cache as well, but can't find the discussion anywhere.
Is this still true today and should I be limiting it alongside the n216 and n144?

Will I see much of a performance gain by allowing all cores to crunch away at N144 with hyper threading enabled, or will this just be twice the time for little if any gain?
Right now I have n144 limited to 8 concurrent on the Ryzen and 4 on the 4770 and 2600 thus theoretically illiminating HT, and 4 216 on the Ryzen with 2 allowed on the 2 intels. I'll change this to 1 per your advice, thank you. Rosetta is currently using the remaining 8 threads of the Ryzen and 4 of the other two. I've been a strong supporter of WCG since 2016 and need a bit of a break from there, though I will try and get some of the arp.