Things are still very much broken- the amount of work In progress continues to fall, as does the number of Tasks processed per 24hrs.
Heaps of work available, but no one (or pretty much no one) can get any of it.

I'm not disagreeing, but where are you seeing that?
I've just looked at Rosetta project credits on Boincstats over the last 40 days and each 7 days over the last few weeks credit 195m, 207m, 282m, 282m, 277m
Or do you mean the last few days specifically?
Still very few unsent on the server status page - just 188 - but now 10.8m queued on the front page
I'm cutting off SiDock and WCG completely now - NNT - and giving Rosetta 100%

Hi,
I think the whole Boinc system is down and has been so since 2024/12/07....

My immediate reaction is to ask just what is the absolute minimum required to prevent Boinc from getting Rosetta beta tasks.

Either the project adds the option in the users account, or they support the anonymous platform function, or BOINC make changes to the supported values for the max_concurrent option in app_config.xml to make it possible to limit the number to less than one (ie- 0),
Any one of those 3 would make it possible.

Respectfully disagree. Take LHC, for example.
Suppose you are running ATLAS and CMS only, both are mentioned in your app_config.xml

Stop right there & read what you posted, and then read what i posted.

As kotenok2000 pointed out, i was talking about using app_info.xml to make use of the Anonymous Platform function.
app_config.xml is completely, totally and utterly different.

I am certain of this. There is no way in any file you can create or modify on your system that will determine whether or not you will be sent tasks for any particular app.

You can if the project supports anonymous platform.
The app_info.xml file contains the information for the applications that your system has, so you will receive work only for those applications & no others.

This won't block Boinc from downloading beta work, and it has no effect all all on the number of cores each task will use.. It will only limit it from running more than X Rosetta tasks simultaneously.
If there were any way to tell Boinc not to download beta tasks, it would be in the cc_config.xml file. I see nothing in the user guide to suggest that is even possible. Therefore, since Rosetta itself does not distinguish between the "old' and beta tasks, it seems there is no way to block a client Boinc from downloading Rosetta beta tasks.

Are you sure? I used the xml file years ago and i remember it "reset" the project folder and started to download only the selected app.
But, probably, I remember wrong.

And, anyway, this is only attempts, until they decide to insert the possibility to choose in the user's profile...

<max_concurrent>-1</max_concurrent> should have been unlimited.

Stuprd boinc thinks <max_concurrent>0</max_concurrent> is unlimited.

You can ask Veneto how to do that modification to block beta work. But I only got one beta and since then nothing but clean 4.20. So is it worth the effort to mess around?

The "usual" app_config.xml
Something like this (if i remember correctly):

<app_config>
    <app>
        <name>rosetta</name>
            <max_concurrent>X</max_concurrent>
    </app>
 </app_config>

(with X you can configure how many cores to use)

<app_version>
        <app_name>ATLAS</app_name>
        <avg_ncpus>2</avg_ncpus>
        <plan_class>vbox64_mt_mcore_atlas</plan_class>
        <cmdline>--nthreads 2</cmdline>
    </app_version>

there's a report button at the bottom of each post.

Which does nothing.
When the spam first started i reported them as they occurred, but nothing was done about them. Apparently the project is happy to have the forums full of spam.

Dedicated nursing writers ensure quality papers. They focus on delivering well-researched and accurate content. Each assignment is tailored to meet your specific needs. These writers have extensive knowledge in nursing. They understand academic standards and expectations. online class help services their goal is to help you succeed academically. With their expertise, you receive clear and concise papers. Every paper is original and free from plagiarism. Trust our dedicated writers for your nursing assignments. Achieve academic excellence with their support.

Oh look everyone..another spammer.
Go away Kinny unless you have something relevant to talk about.
We have enough spam on here.

Haven't received any work units for two or three weeks now , what's up with that?

Fri 02 Aug 2024 04:53:12 AM | Rosetta@home | Scheduler request completed: got 0 new tasks
Fri 02 Aug 2024 04:53:12 AM | Rosetta@home | Project is temporarily shut down for maintenance

Looks like a new CPU application, with, maybe, possibly, a GPU application at some stage (maybe...).

Yes.
But it's the first time that R@H admins speaks explicitly about work for gpu on our computers

If I do get that GPU now, I might just dispense with running CPU-only tasks from Einstein, as the gravitational wave tasks seem to be taking 3/4 of an hour to complete, and earn 10K credits each!

A good GPU application can produce a huge amount of work.

And for the very last time -- the max_concurrent settings should not ever have any influence over Boinc requesting enough work for each project to be able to meet the resource share targets. The only effect they can possibly have is in how long it takes to reach those targets -- which I have painfully tried to suggest, I simply do not care.

I agree- limiting the number of Tasks that can run for a particular application won't stop your Resource Share settings from being met, it just increases the amount of time till it can be done (and that increase can be significant- with low core/thread systems with lots of active project at can take months. But even with your limits, the total number of cores/threads you've got available with only a few projects i would expect a week or two at most for your system (assuming no project issues- then all bets are off)).

And until you explicitly stated you didn't care how long it took, i had no idea that was your position. From the posts you were making i was under the impression you wanted things to sort themselves out sooner rather than later, hence my suggestion to remove the limits.

PS,Boinc seems to be working hard to overcome the massive beating my RAC on LHC took over the past few days -- 21 threads are allotted to LHC as I type.

Or just let things be for a while see how things end up.

You may have misunderstood what I was saying there -- apologies if I caused any confusion. Those 21 threads were all Boinc's doing, not mine.

Yep, i understood it as BOINC's doing, that's why i suggested there leaving things as they are instead of changing them further as i had suggested earlier in the post.

Thus those first 3 lines actually represent the potential use of, not 12, but 20 threads.

Ok, but so what?
If BOINC needs them to honour your Resource Share it can make use of them, if not, then the other projects will make use of them.
But by putting in limits on the number of Tasks of a particular type that can be run, you hamstring BOINC's ability to get work in order to meet your Resource Share settings.

As things are, you've told it what you want to happen with your Resource Share values, but then pretty much tied both it's arms behind it's back by limiting how much it is able to do (even though it's capable of doing much more), and it's just doing what it can, within those very restrictive limits.

Prepare for an avalanche of event log output.

Regardless of what the manual might say, personally, several times over the years, i have removed the the app_config file, exited & restarted BOINC with no issues. If there is no app_config file, then there are no values the Manager can read & then use. So it just runs with the applications defaults (And then later i've put in a modified app_info and just read it in for the values to take effect. I never tried it with the value set to 0, exiting BOINC and restarting after removing the file did the job of undoing what it had done).

PS,Boinc seems to be working hard to overcome the massive beating my RAC on LHC took over the past few days -- 21 threads are allotted to LHC as I type.

Or just let things be for a while see how things end up.

Currently running tasks are: Rosetta and Einstein 8 each (controlled by app_config files)

In what way are the being controller by app_config files?
Whatever settings you've got there will impact on work Scheduling, as the Scheduler will have to work around those app_config settings.

LHC;
<max_concurrent>2</max_concurrent>
<max_concurrent>8</max_concurrent>
<max_concurrent>2</max_concurrent>
<project_max_concurrent>8</project_max_concurrent>
<max_concurrent>8</max_concurrent>
<max_concurrent>2</max_concurrent>
<max_concurrent>4</max_concurrent>

Ok, there's what's limiting how much work & of what type your system can do.

If you're feeling game, i'd suggest making a copy of all of your app_config files and put them somewhere safe.
Then remove the max_concurrent, project_max_concurrent from all of them, exit & restart.

Currently running tasks are: Rosetta and Einstein 8 each (controlled by app_config files)

In what way are the being controller by app_config files?
Whatever settings you've got there will impact on work Scheduling, as the Scheduler will have to work around those app_config settings.

<app_config>
     <app>
        <name>CMS</name>
        <max_concurrent>2</max_concurrent>
    </app>
    <app_version>
        <app_name>CMS</app_name>
        <avg_ncpus>4</avg_ncpus>
        <plan_class>vbox64_mt_mcore_cms</plan_class>
        <cmdline>--nthreads 4</cmdline>
    </app_version>
   <app>
        <name>Theory</name>
        <max_concurrent>8</max_concurrent>
    </app>
    <app>
        <name>ATLAS</name>
        <max_concurrent>2</max_concurrent>
    </app>
    <app_version>
        <app_name>ATLAS</app_name>
        <avg_ncpus>2</avg_ncpus>
        <plan_class>vbox64_mt_mcore_atlas</plan_class>
        <cmdline>--nthreads 2</cmdline>
    </app_version>
</app_config>

<app_config>
   <project_max_concurrent>8</project_max_concurrent>
</app_config>

<app_config>
   <app>
       <name>hsgamma_FGRP5</name>
       <max_concurrent>8</max_concurrent>
   </app>
   <app>
       <name>einstein_O3MD1</name>
       <max_concurrent>2</max_concurrent>
   </app>
<app>
    <name>einsteinbinary_BRP4G</name>
       <max_concurrent>4</max_concurrent>
</app>
</app_config>

I don't know if task run times are at all relevant

Yep, they are.
In theory- A Task on one Project that runs for a month should result in the same Credit as Tasks on another Project that run for only a couple of minutes each, over that month.
But if the long running Task doesn't make use of trickles
<snip>

I'll leave things as they are for now if you think it best, but I have to say, I am sorely tempted to blow that LHC resource share through the roof, say to something like 5000, to see what happens.

Give it until that exceptionally long running Task is done, and hopefully you'll pick up a more usual runtime Task, then see how it behaves.
Otherwise, no more than double the present LHC resource Share value, otherwise LHC will spike up, and the others will fall down, so you'll bump theirs up (or the LHC down again which would be better), then they'll pick up & LHC will fall, so you bump up it's share again, it'll spike the others will fall, rinse and repeat for months till eventually you get tired of it or things get close to what you want.

I'm using 22 threads out of 24 for Boinc. That seems to still leave me plenty of processing power for the rest of the system.

It appears to be plenty- the difference between CPU time & Run time for your Tasks is around 10 min for the 3hr Tasks, which would indicate a moderately busy system if all cores/threads were available to BOINC.

The current days of work settings have been in place only for a few days; I'd been toying with stupidly large values trying to even things out, but I've given up trying -- now Boinc can do what it will do, and I will try to control that as best i can.

If it had some lagre values, then it will take longer for all of that to clear, and the Scheduler to sort things out.
Give it a few more days with the 0.1 & 0.01 values & things should settle down nicely.

If it still doesn't pick up as much LHC work as you would like, then bump up it's Resource Share, and then give it another few days to see what the effect is.