How to customize the new 5.8.8 client?

Message boards : Number crunching : How to customize the new 5.8.8 client?
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile Martin P.

Send message
Joined: 19 May 99
Posts: 294
Credit: 27,230,961
RAC: 2
Austria
Message 512082 - Posted: 2 Feb 2007, 9:44:04 UTC

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!

ID: 512082 · Report as offensive
W-K 666 Project Donor
Volunteer tester

Send message
Joined: 18 May 99
Posts: 19402
Credit: 40,757,560
RAC: 67
United Kingdom
Message 512091 - Posted: 2 Feb 2007, 10:52:02 UTC

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
ID: 512091 · Report as offensive
Profile mikey
Volunteer tester
Avatar

Send message
Joined: 17 Dec 99
Posts: 4215
Credit: 3,474,603
RAC: 0
United States
Message 512097 - Posted: 2 Feb 2007, 11:10:48 UTC - in response to Message 512082.  

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.

ID: 512097 · Report as offensive
zombie67 [MM]
Volunteer tester
Avatar

Send message
Joined: 22 Apr 04
Posts: 758
Credit: 27,771,894
RAC: 0
United States
Message 512176 - Posted: 2 Feb 2007, 16:12:24 UTC

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
ID: 512176 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14679
Credit: 200,643,578
RAC: 874
United Kingdom
Message 512192 - Posted: 2 Feb 2007, 16:45:40 UTC - in response to Message 512176.  
Last modified: 2 Feb 2007, 16:46:14 UTC

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.
ID: 512192 · Report as offensive
Profile Pooh Bear 27
Volunteer tester
Avatar

Send message
Joined: 14 Jul 03
Posts: 3224
Credit: 4,603,826
RAC: 0
United States
Message 512203 - Posted: 2 Feb 2007, 17:13:47 UTC

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
ID: 512203 · Report as offensive
n7rfa
Volunteer tester
Avatar

Send message
Joined: 13 Apr 04
Posts: 370
Credit: 9,058,599
RAC: 0
United States
Message 512225 - Posted: 2 Feb 2007, 18:24:24 UTC

I don't remember, what's the determination for the normal reporting interval?
ID: 512225 · Report as offensive
Profile Pooh Bear 27
Volunteer tester
Avatar

Send message
Joined: 14 Jul 03
Posts: 3224
Credit: 4,603,826
RAC: 0
United States
Message 512233 - Posted: 2 Feb 2007, 18:45:51 UTC - in response to Message 512225.  

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
ID: 512233 · Report as offensive
W-K 666 Project Donor
Volunteer tester

Send message
Joined: 18 May 99
Posts: 19402
Credit: 40,757,560
RAC: 67
United Kingdom
Message 512285 - Posted: 2 Feb 2007, 20:27:58 UTC - in response to Message 512233.  

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.
ID: 512285 · Report as offensive
n7rfa
Volunteer tester
Avatar

Send message
Joined: 13 Apr 04
Posts: 370
Credit: 9,058,599
RAC: 0
United States
Message 512308 - Posted: 2 Feb 2007, 20:51:14 UTC - in response to Message 512285.  

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?
ID: 512308 · Report as offensive
W-K 666 Project Donor
Volunteer tester

Send message
Joined: 18 May 99
Posts: 19402
Credit: 40,757,560
RAC: 67
United Kingdom
Message 512319 - Posted: 2 Feb 2007, 21:06:12 UTC - in response to Message 512308.  

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
ID: 512319 · Report as offensive
n7rfa
Volunteer tester
Avatar

Send message
Joined: 13 Apr 04
Posts: 370
Credit: 9,058,599
RAC: 0
United States
Message 512364 - Posted: 2 Feb 2007, 22:24:05 UTC - in response to Message 512319.  

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.

ID: 512364 · Report as offensive
W-K 666 Project Donor
Volunteer tester

Send message
Joined: 18 May 99
Posts: 19402
Credit: 40,757,560
RAC: 67
United Kingdom
Message 512412 - Posted: 3 Feb 2007, 0:28:10 UTC - in response to Message 512364.  

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
ID: 512412 · Report as offensive

Message boards : Number crunching : How to customize the new 5.8.8 client?


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.