Why do the messages that request work include a varying number of seconds?
Is there any correlation between the number of "seconds" and the amount of time the work takes to complete?

Work fetch depends on your connect to interval and resource share and long term debt (and possibly a few other factors). So different resource shares will lead to different work requests. And if a project hasn't sent work for a while, they work request will tend to go up.

Here's an example from my logs (I use an extremely low connect to interval (.001 days I think) so my work request is very small) and you can see the work request is going up (although very slowly).


4/10/2007 6:11:52 AM|Pirates@Home|Sending scheduler request: To fetch work
4/10/2007 6:11:52 AM|Pirates@Home|Requesting 53 seconds of new work
4/10/2007 6:11:57 AM|Pirates@Home|Scheduler RPC succeeded [server version 509]
4/10/2007 6:11:57 AM|Pirates@Home|Deferring communication for 1 min 0 sec
4/10/2007 6:11:57 AM|Pirates@Home|Reason: requested by project
4/10/2007 6:11:57 AM|Pirates@Home|Deferring communication for 1 hr 56 min 31 sec
4/10/2007 6:11:57 AM|Pirates@Home|Reason: no work from project
4/10/2007 10:14:23 AM|Pirates@Home|Sending scheduler request: To fetch work
4/10/2007 10:14:23 AM|Pirates@Home|Requesting 55 seconds of new work
4/10/2007 10:14:28 AM|Pirates@Home|Scheduler RPC succeeded [server version 509]
4/10/2007 10:14:28 AM|Pirates@Home|Deferring communication for 1 min 0 sec
4/10/2007 10:14:28 AM|Pirates@Home|Reason: requested by project
4/10/2007 10:14:28 AM|Pirates@Home|Deferring communication for 1 hr 57 min 25 sec
4/10/2007 10:14:28 AM|Pirates@Home|Reason: no work from project
4/10/2007 12:11:55 PM|Pirates@Home|Sending scheduler request: To fetch work
4/10/2007 12:11:55 PM|Pirates@Home|Requesting 55 seconds of new work
4/10/2007 12:12:00 PM|Pirates@Home|Scheduler RPC succeeded [server version 509]
4/10/2007 12:12:00 PM|Pirates@Home|Deferring communication for 1 min 0 sec
4/10/2007 12:12:00 PM|Pirates@Home|Reason: requested by project
4/10/2007 12:12:00 PM|Pirates@Home|Deferring communication for 3 hr 42 min 23 sec
4/10/2007 12:12:00 PM|Pirates@Home|Reason: no work from project
4/10/2007 3:54:28 PM|Pirates@Home|Sending scheduler request: To fetch work
4/10/2007 3:54:28 PM|Pirates@Home|Requesting 56 seconds of new work
4/10/2007 3:54:33 PM|Pirates@Home|Scheduler RPC succeeded [server version 509]
4/10/2007 3:54:33 PM|Pirates@Home|Deferring communication for 1 min 0 sec
4/10/2007 3:54:33 PM|Pirates@Home|Reason: requested by project
4/10/2007 3:54:33 PM|Pirates@Home|Deferring communication for 1 min 0 sec
4/10/2007 3:54:33 PM|Pirates@Home|Reason: no work from project


But I don't understand the scheduler in any more depth than that.

There's a sorta correlation between the work request and time to completion. The server will calculate how many work units are needed to fill that number of seconds and send that many, but not more.

So if a work request is for 10000 seconds of work, and given your benchmarks and DCF it will take your computer 5000 seconds to complete it, you'll get 2 work units. If it'll take you 9000 seconds to complete, you'll get 1. If it'll take 3000 seconds, you'll get 3. But even if you make a work request for 1 second worth of work, you'll get 1 work unit.


At least, that's my understanding of how the thing works. There are few people that can say they *really* understand how the scheduler works.

The server should (and I think it does) send 2 work units. Else the client would ask for the "missing" 1000 seconds with a second request.

You think there are? ;-)

Norbert

Well... there's has to be at least a few who understand it. The code didn't write itself :0)

However, I'm definitely not one of those people as is obvious by my last post.

It does indeed send 2 WU's, otherwise it would not be possible to get CPDN work units.

This is not very nice to the project, if possible you should set it to report results in batches. Here is a nice article about the evils of returning results immediately.

A low connect to interval doesn't harm the server. The client does not connect 1000 times per day. On the contrary, the client now "knows" that it can wait longer to report the result because it will be able (if necessary) to connect during the next minute.

Norbert

I've read what Rom has to say and I'm very aware of reporting in batches. I run multiple projects/projects with long WUs. One computer is running Einstein/BURP/Priates/BOINC Alpha/Leiden. The other is running Predictor/Docking/CPDN Beta/BOINC Alpha/Pirates. So even though my connect internal is very small, I don't bug the servers very frequently.