You are changing the correct setting.

As far as I can tell, the problem arises because the client sends a scheduler request, and gets the new preferences. The new preferences force it to immediately contact the scheduler again, but BOINC has a limiter to prevent misuse. So you get the error.

Try again after 10 minutes. Or just leave it - BOINC should back off the scheduler request and retry after a safe interval.

Hi ParoxysM,
I assume that you are on dialup or something similar. You can get all the back-and-forth accomplished quickly on one call if you have it set to something like 'communicate every .001 days'. When you start increasing the delay to several days, the back-and-forth slows down enormously. Patience.

Lawrence

I wonder whether that is one of the disadvantages of slow machines -- The fast ones blast out a BOINC quorum of 4 and anything else trying to run that same workunit could be too late. 19 does seem like a very large pile of waiting work for a slow machine. It must still be set on 20 days. That's extremely close to the 3 week limit. You may be compounding the problem if you have a power outage and workunits can't be completed. Each fast AMD machine here with the connection profile set to 2.0 days seems to have between 5 and 10 workunits sitting around most of the time. They are finishing 4-5 workunits per day each, so that's about right. I'm getting points for them, also, so I'm part of the mix.

Yes, it just delays things if you request a random update. Wait for something to finish and then connect to the network. If the transfer has a delay since it was previously trying and backed out, you can retry each upload dataset. The upload will get done and "ready to report". Update the project. A result will be reported, and optionally there will be some work to send you. Check the message log. I don't get new work after sending every result. Downloads only happen sometimes.

FAAH also uses tiny files that don't take long to upload/download. I can grab a new workunit on dialup in a couple of minutes. The HPF files are killers, and it takes a whole evening to replace a few workunits.

@ParoxysM, suggest you make a table of settings for each machine and include which device profile set on WCG-BOINC applies to each of the machines. Are they all using the same (the default you set at WCG e.g.). Speculating, if machines are going thru at 12-15 WU's a day, yet you have the profile set for 20 days, you wont get work.....but that makes no sense, since my observation is, that if you are threatning to run out of work, BOINC will fetch a new one anyway (if it can get connected!!!!!!).

@ All others...had that RPC report once, this very morning. Anticipated WU finishing 5 minutes before 06:00 UTC, hit the Project update button 9 minutes before 06:00 UTC. The WU product got uploaded 05:56 UTC, then the below came back.....WCG still included the result as it was send before said 6 hourly update and validated in a minute. Immediately after the 600 second compulsary wait, a new WU was fetched, as the last WU had just started at 05:57.

11-5-2006 8:01:21|World Community Grid|Scheduler request succeeded
11-5-2006 8:01:21|World Community Grid|Message from server: Not sending work - last RPC too recent: 545 sec

Long short, all i think is fine. I just hit the project update button, because only then will BOINC seemingly fetch the scores and update the graphs. Main difference maybe, my machine is on net 24/7 (and behind 4 layers of firewalling, antivirus, antispy/antisnoop, should any hacker get notions).

*update*

I left the machines connected to the LAN overnight and they all obtained a ton of work...w00t!! Im going to leave my settings where they are for a week and back it down if I see an issues. Thanks for the input and help to lower my rank - Current Ranking: 185