Questions and Answers :
Wish list :
Better choices for control of multiple projects
Message board moderation
Author | Message |
---|---|
bobpeasley Send message Joined: 27 Oct 03 Posts: 3 Credit: 524,568 RAC: 0 |
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. |
John McLeod VII Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0 |
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. |
Ken Switzer Send message Joined: 10 Sep 99 Posts: 7 Credit: 185,062 RAC: 0 |
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 |
Keck_Komputers Send message Joined: 4 Jul 99 Posts: 1575 Credit: 4,152,111 RAC: 1 |
> 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 |
Heffed Send message Joined: 19 Mar 02 Posts: 1856 Credit: 40,736 RAC: 0 |
> 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. |
Nightowl- i5-750 Send message Joined: 17 Feb 01 Posts: 202 Credit: 5,057,974 RAC: 0 |
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 |
Ken Switzer Send message Joined: 10 Sep 99 Posts: 7 Credit: 185,062 RAC: 0 |
> > 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 |
Heffed Send message Joined: 19 Mar 02 Posts: 1856 Credit: 40,736 RAC: 0 |
> 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] |
Thomas Maxwell Send message Joined: 2 Jun 99 Posts: 13 Credit: 168,027 RAC: 0 |
|
©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.