The client has no concept of sub-projects, it just schedules based on total work in queue, for a project and overall. The 'then' developer himself wrote that he had issue with how app_config was put in, but it was something I think WCG pushed down the Berkeley pipe... because the long forgotten [by most] app_info.xml actually did interact with the servers to tell No I don't want this or that, and it interfered. It's why me and others have been asking for an option to limit WU per project as it is drowning out the cache to the point that buffer is full and cores are idling, [see my previous posts on this, particular on FAHB doing/done this]. Because the issue is thoroughly ignored I just do NOT hesitate to operate the abort button, such as when 260 FAHV Rigid were in my queue saying they were 14 minutes, but each ran over 6 hours... I did a select all and hot the 'go elsewhere' button. Combined with the DCF locking which prevents the client from recomputing the TTC for unstarted work, a problem of WCGs own making.

End [again].

Edit, the lone comment from techs is.... it was for CEP2, to limit the max_concurrent (the inference with that statement I leave unsaid)

Right now I see a couple *_1 / *_2 or even *_3 units incoming...
But I also have a couple *_0 incoming as well, so I wonder how this will evolve :)
I am curious about the availability of these units since I am now heading for the diamond badges in this project as well. :) I guess I find out within the next hours...
Crunch on! :)

Roughly 9,000 WUs are getting returned daily (source), so there is supply but not a wide supply for now.

Yep, added this project to the mix at around 6:30am and by 7:00am one of my machines had picked up a unit, it's sat behind a fair few SCC units but should hit cores within the day.

Hoping that this is the first of many units my cluster will chug through.

On with the crunch!!

Daily stats - by Project >> FAH2 can tell you what is happening. Check out the info under the "Yesterday" heading, eg on 16 Feb 17 we returned 12 years worth of crunch time.

I've been crunching mainly FAHV for a while, but have just completed a few FAH2s.
I notice that they are still the original trickle-up WUs, not the anticipated new AsyncRE type.

It may be that the scientists & techs are restricting the flow of FAH2 WUs because the work will be performed much more efficiently when AsyncRE arrives. They may be maintaining the trickle-down mainly so that devices which have only FAH2 selected will not be idle.
I'm switching away from FAH2 again for now, anyway.
Hint: When AsyncRE is deployed, it would be useful if this was notified in an emailed WCG News digest.