Better choices for control of multiple projects

Questions and Answers : Wish list : Better choices for control of multiple projects
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile bobpeasley

Send message
Joined: 27 Oct 03
Posts: 3
Credit: 524,568
RAC: 0
United States
Message 12896 - Posted: 27 Jul 2004, 23:40:16 UTC
Last modified: 27 Jul 2004, 23:45:16 UTC

I have been running SETI and am now trying to run multiple projects on a couple of machines. I would like to prioritize SETI and just run the other projects (which are beta) at a much smaller rate. The current methodology is not good enough. Even though I have put PREDICTOR at 1 and SETI at 100, PREDICTOR has downloaded quite a few work units while SETI is having I/O problems and only periodically allows for connections. That's okay, but today I see that PREDICTOR work units have shorter expiration periods. SETI allows two weeks for processing but PREDICTOR appears to be several days shorter (could be a full week shorter...)

Anyway, BOINC processes the work units that expire first! So now the work units that I have most recently downloaded are being processed before SETI work units that were previously downloaded. This just skews the computer workload more in favor of PREDICTOR even though I did all that I could to prioritize SETI. Now I have seen recommendations to counter that by shortening the amount of data (work units) that is downloaded (i.e. 1/2 to a full day vice 3,5, or more days.) That won't help much, especially if one project is only online once or twice a day while another is up most of the time. I think there should be special "project" settings in addition to the general preference settings for BOINC.

Anybody got any better suggestions? Otherwise it seems to be the luck of the draw just as much as any settings I can adjust. I'm happy to share processing across multiple projects but would like to have more control, especially when supporting alpha/beta testing.
ID: 12896 · Report as offensive
John McLeod VII
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 15 Jul 99
Posts: 24806
Credit: 790,712
RAC: 0
United States
Message 12933 - Posted: 28 Jul 2004, 1:52:51 UTC

When attempting to download work, BOINC first tries the project that has the largest resource debt. If there is no work from the project with the largest resource debt, BOINC will download work from someplace. Since S@H has spent so much time off, the alternate project is bound to dominate your CPU usage. There is no technique that will keep your CPU busy and keep you processing your preferred project if there is no work from your preferred project.

The short deadlines for Predictor will delay the processing of SAH WUs, but it will not affect the long term average that much. If a few predictor WUs are crunched, then S@H will keep getting the first attempt at download.

All that you have been feeling is the lack of work from S@H, not a problem with the settings.

ID: 12933 · Report as offensive
Profile Ken Switzer

Send message
Joined: 10 Sep 99
Posts: 7
Credit: 185,062
RAC: 0
United States
Message 12950 - Posted: 28 Jul 2004, 3:08:20 UTC

I do not believe your answer!
How can it possibly balance when every time new work units come in they have
a shorter expiration period. I have watched several times when the low water mark is hit - more predictor WUs come in and run first before SAH even when there are WUs to be run that were already downloaded from SAH.
I think you need to rethink the mechanism or ask Predictor to set the
same expiration dates as SAH.
I would like to be proven wrong - but my observation is otherwise.
kws
ID: 12950 · Report as offensive
Profile Keck_Komputers
Volunteer tester
Avatar

Send message
Joined: 4 Jul 99
Posts: 1575
Credit: 4,152,111
RAC: 1
United States
Message 12952 - Posted: 28 Jul 2004, 3:12:54 UTC - in response to Message 12933.  

> When attempting to download work, BOINC first tries the project that has the
> largest resource debt. If there is no work from the project with the largest
> resource debt, BOINC will download work from someplace. Since S@H has spent
> so much time off, the alternate project is bound to dominate your CPU usage.
> There is no technique that will keep your CPU busy and keep you processing
> your preferred project if there is no work from your preferred project.
>
> The short deadlines for Predictor will delay the processing of SAH WUs, but it
> will not affect the long term average that much. If a few predictor WUs are
> crunched, then S@H will keep getting the first attempt at download.
>
> All that you have been feeling is the lack of work from S@H, not a problem
> with the settings.
>
To add to this patience is the key. The percentages displayed are what BOINC will attempt to maintain over a period mesured in weeks or months. That period does not include the first week to month after adding a new project also.

John Keck
BOINCing since 2002/12/08
ID: 12952 · Report as offensive
Heffed
Volunteer tester

Send message
Joined: 19 Mar 02
Posts: 1856
Credit: 40,736
RAC: 0
United States
Message 13023 - Posted: 28 Jul 2004, 8:47:27 UTC - in response to Message 12950.  
Last modified: 28 Jul 2004, 8:50:37 UTC

> I do not believe your answer!
> How can it possibly balance when every time new work units come in they have
> a shorter expiration period. I have watched several times when the low water
> mark is hit - more predictor WUs come in and run first before SAH even when
> there are WUs to be run that were already downloaded from SAH.

It works Ken.

It doesn't matter if Predictor has shorter deadlines which pre-empt S@H WU processing. When Predictor starts getting ahead of S@H, S@H will be the only WUs downloaded.

The problem is that S@H isn't able to supply work on a consistant basis, so you really aren't seeing the resource share in action.

You're getting work from Predictor because S@H is down whenever you ask for work. (assuming your resource debt is equalized) It's not Predictors fault S@H is down, so you can't expect them to adjust their deadlines to make up for this fact just so your S@H units will run sooner than theirs. In fact, what you are asking for would put the other project at risk by delaying their deadlines. You want BOINC to favor S@H, which could cause the earlier expiring Predictor WUs to miss their deadline.

Yes, some Predictor WUs might take precedence over S@H due to their deadline date, but any delay in getting S@H WUs processed is ultimately S@H's fault. If the work would have been there, it would have been downloaded instead of Predictor.
ID: 13023 · Report as offensive
Profile Nightowl- i5-750
Volunteer tester

Send message
Joined: 17 Feb 01
Posts: 202
Credit: 5,057,974
RAC: 0
Canada
Message 13041 - Posted: 28 Jul 2004, 10:54:07 UTC

I tried predictor but it keeps downloading and running those instead of seti so I canned it and am staying with both versions of seti.

ttyl
Jeff (Nightowl)
All your answers in one spot:
http://setiweb.ssl.berkeley.edu/transition.php
ID: 13041 · Report as offensive
Profile Ken Switzer

Send message
Joined: 10 Sep 99
Posts: 7
Credit: 185,062
RAC: 0
United States
Message 13099 - Posted: 28 Jul 2004, 14:22:41 UTC - in response to Message 13023.  

> > I do not believe your answer!
> > How can it possibly balance when every time new work units come in they
> have
> > a shorter expiration period. I have watched several times when the low
> water
> > mark is hit - more predictor WUs come in and run first before SAH even
> when
> > there are WUs to be run that were already downloaded from SAH.
>
> It works Ken.
>
> It doesn't matter if Predictor has shorter deadlines which pre-empt S@H WU
> processing. When Predictor starts getting ahead of S@H, S@H will be the only
> WUs downloaded.
>
> The problem is that S@H isn't able to supply work on a consistant basis, so
> you really aren't seeing the resource share in action.

>
> You're getting work from Predictor because S@H is down whenever you ask for
> work. (assuming your resource debt is equalized) It's not Predictors fault
> S@H is down, so you can't expect them to adjust their deadlines to make up for
> this fact just so your S@H units will run sooner than theirs. In fact, what
> you are asking for would put the other project at risk by delaying their
> deadlines. You want BOINC to favor S@H, which could cause the earlier expiring
> Predictor WUs to miss their deadline.
>
> Yes, some Predictor WUs might take precedence over S@H due to their deadline
> date, but any delay in getting S@H WUs processed is ultimately S@H's fault. If
> the work would have been there, it would have been downloaded instead of
> Predictor.
>
>
OK - I can see how it could work in the future - but it isn't working now.
I guess I just have to wait until SAH gets their problems fixed.
Thanks for explaining the particular circumstances we are under and why in the short term it isn't working. I just have to be more paitient.
kws
ID: 13099 · Report as offensive
Heffed
Volunteer tester

Send message
Joined: 19 Mar 02
Posts: 1856
Credit: 40,736
RAC: 0
United States
Message 13181 - Posted: 28 Jul 2004, 18:38:59 UTC - in response to Message 13041.  

> I tried predictor but it keeps downloading and running those instead of seti
> so I canned it and am staying with both versions of seti.

This is because you didn't wait for the resource debt to balance. It is expected for a new project to dominate the processing time for a week or two until the resource debt is matched.

<a> [/url]
ID: 13181 · Report as offensive
Profile Thomas Maxwell
Volunteer tester

Send message
Joined: 2 Jun 99
Posts: 13
Credit: 168,027
RAC: 0
Sao Tome and Principe
Message 25108 - Posted: 11 Sep 2004, 14:04:12 UTC

bobpeasley, please phone home :-D


<A>Team ThunderDawg[/url]
ID: 25108 · Report as offensive

Questions and Answers : Wish list : Better choices for control of multiple projects


 
©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.