Interesting posts since my last - I like that "they're doing them in ascending order of generations" idea...

Adri -- I also collected a "Normal" [135] singleton with lots of MCM1 as neighbours! This is as reported by one of my scripts (though I've cut a lot of system-related stuff and the wingman data!):

Task ARP1_0032362_135_0 was returned by Zen3700 at 2022-12-27T06:37:02+0000:
  Work-unit 236642878 created 2022-12-26T22:35:30+0000
  Sent date 2022-12-26T22:46:56+0000,  deadline 2023-01-01T22:46:56+0000.
  status is Valid

An interesting thing I spotted about the surrounding MCM1 tasks -- they all had a later work unit creation date (around 22:46 UTC)...

I also agree that it would be nice to know what the state.txt query is -- However, I have precious little hope of that, as I said...
Perhaps the reference to user-based forensics was a bit too broad, but...

----

I'm not sure which is worse -- the odd singleton every now and then, or no work until a larger number of units might be released... If I knew we were stuck with the former, I'd re-organize my WCG workload constraints to ask for less ARP1 and allocate it less slots (and possibly even re-start CPDN now they have some 64-bit Linux work...) As it is, I've got cores idling because of the way I'm set up to stop MCM1 swamping ARP1 :-)

Cheers - Al.

Mike,

I do similarly on the two machines with enough L3 cache that I'm willing to let them run ARP1 (or CPDN). The "swamping" isn't so much what I download as the order in which things run! :-)

To resolve that I have mine set up using max_concurrent as a limiter at the client end then I use the allowed download limits in the profiles to try to control turnaround time, my aim being that everything sent by WCG should get returned within 24 hours (unless it' was one of those awkward ARP1 tasks that overran my normal 9 to 12 hour run times for one reason or another) -- I only allow BOINC 6 threads out of 8 on my i7 and 11 out of 16 on my Ryzen (non-WCG GPU tasks don't eat into that allowance as they are set to fractional CPU use), as I found that allowing more threads was actually counter-productive (there are also background activities on both systems; databases, stats gathering daemons, and so on, and those also affect performance)

My problem now is that if ARP1 is only going to be drip-fed, I'd rather be doing CPDN work (where I know there's about to be a constant stream of jobs that require about the same amount of effort per task as ARP1... I'll happily switch my three Ryzen threads away in that case, though I don't think the Intel box would do as well - limited L3 cache by comparison! - so that might stay on ARP1 but set for only one task and not caring if it gets drowned out...

I'd just like to be told what's going on (as would we all, I presume!) so I can do short-term planning - is that too much to ask, I wonder?

Cheers - Al.

I prefer ARP, but I haven't seen one in a while, so I'm going for my 1 yr MCM badge and running 4 MCM (3 extra in waiting). If any ARP show up, I'll trim the MCM queue, but even polling the server now and then I'm only getting MCM. I have another machine to put into service once they can give us more ARP than we can handle.

Congrats to those who win the lottery and get the ARPs.

\I actually received a new unit yesterday. It will be finished today.

Mike

So many days just with MCM units. When Krembil will take any action to solve this frequent shortage of taks for many projects here? Need plan more it. Need increment WCG with more projects and so on.