The 'panic' state can be triggered automatically by setting a fake cache (aka connect every) to half the deadline of ARP. Given that the website profiles can be set to a hard number of tasks to buffer, of which the client is unaware, there will be continuous attempts to connect.

One warning with that, IIRC. if ALL threads of BOINC run in high priority the work fetching stops too.

BOINC development seems to be pretty much 'maintenance' and -volunteers- only, have no high expectations of anything advanced happening on both client and server side software.

Dang, this conversation got deep quickly :)

Api, to give you an idea on why we use that avg turn around is due to caches. You can set your cache to 10 days if you wanted to. This means that even though your machine is reliable, it may have the turn around of 10 days per work unit. If we set the deadline to 35% of a 10 day deadline, your machine would be putting results in higher priority more often. Now, you're still considered a reliable host, but we have a slew of results that need reliable, meaning that your queue is now filled with 10 days of results (I know extreme case, but for my point) that need to be returned in 3.5 days...you have 6.5 days of work that is going to be 'too late'. These work units would then need to be resent to another host after your deadline is missed to a machine that is reliable and your machine would now be marked as unreliable because you had results considered bad.

The avg turn around was set many moons ago...when most of our applications were around the 4-6 hour range, this meant it was set for 6-9 times the avg workunit return pace. With these larger workunits that was now closer to 1.5 times a workunit length....thus needing to be tested at a higher time.

There was discussion to make this setting at the application level instead of project wide, but we are experimenting with the setting change as adding that feature would take considerably more time to write and test. Changing the setting for our smaller project runtimes shouldn't affect them much, but we are watching those as well. This setting should increase the storage needed on our backend since it'll cause batches to return slower as mentioned above.

What are these hidden targets you're looking for? The setting for becoming reliable wasn't purposefully hidden, but more technical then say the average user (99%) would care to know about. Are there other hidden targets you're wanting to know about?

DrMason, welcome to the forums. Thanks to you and hchc for constructive conversation.

Thanks,
-Uplinger

So then... How can I get my first WU for this project? Not one assigned WU yet, not sure what I need to do. Can't be reliable or unreliable if I can't even get one WU.

What kind of machine are you running and how many cores ? Right now the ARP work units are few and far between. There are several hundred thousand cores looking for just a couple of thousand work units each day. If you are patient, and I am sure you are, you will eventually get one.
Cheers

I am short 3 days from gold. I got most of them at 38 min after hour, prior to the fairer introduction of randomization to HSTB & ARP. I have now gone with the route of a randomized task manager. Much less of a fish in barrel situation, but fair to everyone.