Hi,

how can I implement the <return_results_immediately/> command into the new client? With the truxoft optimized client this was easy, but how do I do that with the PPC- and the Windows-client 5.8.8?

Thanks in advance!

---

The return immediately command was not meant to be released to us the general public, only to be used for testing purposes. It was discovered and used by trux and other BOINC optimisers.
But it does cause lots more work for the servers when only one instead of a bunch of units is reported, and is to be discouraged.

Andy

Hi,
how can I implement the <return_results_immediately/> command into the new client? With the truxoft optimized client this was easy, but how do I do that with the PPC- and the Windows-client 5.8.8?
Thanks in advance!

When you return a unit to the server it takes about 11 seconds for the server to say hi, check the path, open the path, say send the files, receive the files, make sure they got there okay, close the path, say by and hang up with you. If you do this for just one file it wastes server time and the other almost 200,000 of us users will never get thru. It only adds a second or 2 if you send multiple files instead of just one at a time.

---

I'm confused. There are two steps that happen to return a result:

1) Uploading: Actually transferring the completed result to the server. You see this happen on the transfers tab. When complete, the result status changes from Uploading to Ready To Report.

2) ? (not sure what it's called): When the server acknowledges receipt. The result status changes from Ready To Report, to being removed from the task list.

#1 (Uploading) happens immediately upon completion with the *standard* client. This is where the bandwidth is actually consumed.

So what does return_results_immediately actually do, other than having the server acknowledge the returned result? How much of a load can this step actually be?

---

Dublin, California
Team: SETI.USA

I'm confused. There are two steps that happen to return a result:

1) Uploading: Actually transferring the completed result to the server. You see this happen on the transfers tab. When complete, the result status changes from Uploading to Ready To Report.

2) ? (not sure what it's called): When the server acknowledges receipt. The result status changes from Ready To Report, to being removed from the task list.

#1 (Uploading) happens immediately upon completion with the *standard* client. This is where the bandwidth is actually consumed.

So what does return_results_immediately actually do, other than having the server acknowledge the returned result? How much of a load can this step actually be?

I asked that question a few months ago, and Rom Walton (BOINC Developer) posted a blog in reply: BOINC Client: The evils of 'Returning Results Immediately'.

I'm not sure that I'm 100% convinced, but I've set myself a personal limit: if a computer has a RAC of 100 or more, I won't use Return Results Immediately (it'll fetch work and report often enough anyway). But for slow machines like my 400MHz Celeron, I do use RRI, because otherwise results would have to wait an extra couple of days before being purged from the database.

Think of it this way, when you upload the unit, it does nothing to the database at that time, so it stays closed. Only the upload server keeps this information cached until a report happens.

A report opens the database, inserts the information about the unit you returned, check to see if it is a quorum and sends that information down the line to the validators, etc. If you send back on report or 20, the database is opened once, and takes approximately the same time. The online database is also the same database that the forums are all connected to, etc. So those being opened just for a single report is a waste in time.

---

My movie https://vimeo.com/manage/videos/502242

I don't remember, what's the determination for the normal reporting interval?

---

I don't remember, what's the determination for the normal reporting interval?

The ones I remember are: Fetch new work, manual update, approximately 24 hours before due date. I thought there was another.

---

My movie https://vimeo.com/manage/videos/502242

I don't remember, what's the determination for the normal reporting interval?

The ones I remember are: Fetch new work, manual update, approximately 24 hours before due date. I thought there was another.

At next normal connect to interval.

I don't remember, what's the determination for the normal reporting interval?

The ones I remember are: Fetch new work, manual update, approximately 24 hours before due date. I thought there was another.

At next normal connect to interval.

And that is determined how?

---

I don't remember, what's the determination for the normal reporting interval?

The ones I remember are: Fetch new work, manual update, approximately 24 hours before due date. I thought there was another.

At next normal connect to interval.

And that is determined how?

The "connect to" interval is the same one you use to set your work cache. So if that is at one day, and if the computer has no other requirement to contact the mothership, it will do so after one day, since last contact, and report all the units completed and uploaded.

Normally if setting haven't changed and comms is allowed at all times, the computer will require more work before the "connect to" interval and will report uploaded units at the same time. as shown here -

02/02/2007 15:44:25|SETI@home|Sending scheduler request: To fetch work
02/02/2007 15:44:25|SETI@home|Requesting 48554 seconds of new work, and reporting 4 completed tasks
02/02/2007 15:44:30|SETI@home|Scheduler RPC succeeded [server version 507]
02/02/2007 15:44:30|SETI@home|Deferring communication for 11 sec
02/02/2007 15:44:30|SETI@home|Reason: requested by project

Andy

I don't remember, what's the determination for the normal reporting interval?

The ones I remember are: Fetch new work, manual update, approximately 24 hours before due date. I thought there was another.

At next normal connect to interval.

And that is determined how?

The "connect to" interval is the same one you use to set your work cache. So if that is at one day, and if the computer has no other requirement to contact the mothership, it will do so after one day, since last contact, and report all the units completed and uploaded.

Normally if setting haven't changed and comms is allowed at all times, the computer will require more work before the "connect to" interval and will report uploaded units at the same time. as shown here -

02/02/2007 15:44:25|SETI@home|Sending scheduler request: To fetch work
02/02/2007 15:44:25|SETI@home|Requesting 48554 seconds of new work, and reporting 4 completed tasks
02/02/2007 15:44:30|SETI@home|Scheduler RPC succeeded [server version 507]
02/02/2007 15:44:30|SETI@home|Deferring communication for 11 sec
02/02/2007 15:44:30|SETI@home|Reason: requested by project

Andy

What you're saying is it won't connect until it's out of work.

I hope that's wrong.

I think it's some fraction of the cache time. Like every 2.4 hours if your cache is set to 1 day.

I'm just trying to find the fraction.

---

I don't remember, what's the determination for the normal reporting interval?

The ones I remember are: Fetch new work, manual update, approximately 24 hours before due date. I thought there was another.

At next normal connect to interval.

And that is determined how?

The "connect to" interval is the same one you use to set your work cache. So if that is at one day, and if the computer has no other requirement to contact the mothership, it will do so after one day, since last contact, and report all the units completed and uploaded.

Normally if setting haven't changed and comms is allowed at all times, the computer will require more work before the "connect to" interval and will report uploaded units at the same time. as shown here -

02/02/2007 15:44:25|SETI@home|Sending scheduler request: To fetch work
02/02/2007 15:44:25|SETI@home|Requesting 48554 seconds of new work, and reporting 4 completed tasks
02/02/2007 15:44:30|SETI@home|Scheduler RPC succeeded [server version 507]
02/02/2007 15:44:30|SETI@home|Deferring communication for 11 sec
02/02/2007 15:44:30|SETI@home|Reason: requested by project

Andy

What you're saying is it won't connect until it's out of work.

I hope that's wrong.

I think it's some fraction of the cache time. Like every 2.4 hours if your cache is set to 1 day.

I'm just trying to find the fraction.

The scheduler will always request new work if it running low, and network access is allowed. At that point it will also report any completed units. It will only run out of work if you don't allow network access.
It will even request work when a unit processes quicker than the initial "To Completion" time and the RDCF is reduced. And I have seen a request for new work, immmediately after completion of a benchmark when the figures were higher than the previous benchmark.

I am pretty sure that cache time will run to its full length if there is no other reason to connect to the mothership. My Pent M recently downloaded 4 units from Einstein, about 18hrs of work, when Seti and SetiB were both off, even though its resource share is only 4.17%, 1hr/day. It had three results completed and 'waiting to report' before contacting Einsteins servers about a day later. It didn't request new work as it still had most of fourth to do and LTD was high.

Andy