Don't think so. BOINC can only process one scheduler request (to one project) at a time, but once that request has been acknowledged or timed out, it's free to send a request to the next project in line. The requested backoffs only apply to the project that requested them.

Ok, was just guessing. Problem solved by setting Seti to NNT and instantly all projects woke up and started the scheduler connections and timers.
Caches refilled for my other projects.
Problem was definitely caused by Seti. Whatever it was.

Reset the project? Detach and reattach?

Had already tried that... sorry should have mentioned that. It turned out that it stopped liking our custom BOINC clent for some reason though it had worked originally. Replacing boinc, boinccmd, boincmgr and switcher with copies from the AIO archive caused BOINC to redownload the project as if I'd done a detach/reattach, and then it started requesting work on all of three of the affected computers.

Problem was definitely caused by Seti. Whatever it was.

If you have a long timeout set for http activity, and the SETI server wasn't responding in a timely fashion, that might explain it. My machines have been open for SETI resends throughout my high-activity period here, and some have even arrived this morning, so SETI work requests by themselves weren't your problem.

Problem was definitely caused by Seti. Whatever it was.

If you have a long timeout set for http activity, and the SETI server wasn't responding in a timely fashion, that might explain it. My machines have been open for SETI resends throughout my high-activity period here, and some have even arrived this morning, so SETI work requests by themselves weren't your problem.

I actually have a shortened timeout value from default. 60 seconds.
Problem was the way that Seti is configured now and the custom client not agreeing. Suspending Seti solved the issue.

... and the custom client not agreeing.

Not a good design decision to have a client that doesn't back off when, and for as long as, the project requests. What does it do when the project requests a 1 hour break for maintenance?

... and the custom client not agreeing.

Not a good design decision to have a client that doesn't back off when, and for as long as, the project requests. What does it do when the project requests a 1 hour break for maintenance?

Don't know. That is for Ville to figure out why the client has broken with Seti active. Most of the feature set in the client is to manipulate Seti and now that Seti is no longer distributing work, it is simplest to just suspend the project.

The other features of the client are still desirable with the ability to finally control exactly how much work you want on every project no matter the size of the global cache. For once Einstein does not need to be constantly micromanaged and Milkyway will constantly refill its cache and not go dormant every ten minutes because the administrators have never figured out the correct server side configuration files.

i seem to be the only person not having issues with SETI work requests impacting other projects. I'm using the custom client also. but I also run a manual watch command to virtually "click" the update button for SETI every 15 mins regardless of anything else. maybe that's keeping it going for me?

---

I was running a watch command for a while but I discovered it had an impact also and prevented me from getting work from my other projects. So I stopped using it. But that was from before the end of Seti and the recent change in the timer.

i seem to be the only person not having issues with SETI work requests impacting other projects.

no, you are not the only one :-)
I havn't had any such problems either

I was running a watch command for a while but I discovered it had an impact also and prevented me from getting work from my other projects. So I stopped using it. But that was from before the end of Seti and the recent change in the timer.

I don't see how clicking update on SETI on a set interval can prevent you from getting work on another project. I have mine set on SETI now checking every 20.5mins just to prevent it from going into a long backoff, and since I have no seti work, it's only keeping it updated on trying to get some resends.

it's working fine. I get a handful of resends every day from SETI and I'm getting my normal 2 per GPU from GPUGRID on the systems running that, and on the system running Einstein it's getting work consistently, though I run a 0 resource share there, so it only sends me 1 job per GPU + 1 extra. I don't have any special settings for any project in the config file, only settings for SETI.

---

I don't understand how it did either. But it did and the effect was incontrovertible. You don't run all my projects concurrently either I bet.
Just how all my projects interact with each other I guess.