> Experiment to resolve cache deadline issue when running multiple projects on
> one computer. Made separate directories for each project. Installed BoincCLI
> in each and attached to just one project, in my case just S@H and E@H. Used
> Webmin in my Linux system to create 3 cron jobs to turn projects on and off.
> To turn off each project just issed killall boinc_4.19_i686-pc-linux-gnu via
> cron. Killing Boinc also kills the project client which is a child process.
> So don't have to keep track of project client version number. Cron job
> wouldn't directly turn on the project(s) for some reason, got "another
> instance of BOINC running" error message (permissions/lockfile issue?), but
> top or ps didn't show anything running. So used a couple of short bash
> scripts #!/bin/sh, then cd /path to project directory/, then
> ./boinc_4.19_i686-pc-liux-gnu &. Made scripts executable. Then used cron
> to start each project via its bash script. Had to use two scripts because
> each project is in a separate directory.
>
> Setup has been running for two days without problems. Advantages are you have
> complete control of run time for each project, run S@H from 9am to 5:59pm and
> run E@H from 6pm to 8:59am when E@H is less likely to be interrupted. Have
> complete control of cache for each project so can adjust for deadline.
> Noticed if running multiple projects from a single Boinc client that the most
> recent cache setting migrates to all project webpages. Since I have other
> computers running only S@H these were effected also, so I can now keep the
> cache limit I want. Some disadvantages are that more manual overhead is
> involved in setting up the projects. If a project runs out of wu's Boinc now
> won't automatically switch over to aother project, but having independant
> control of the cache makes this less likely. System working in Linux, should
> also work on a recent Mac since nix based, don't know if Windows has a similar
> cron function. Will migrate to other computer systems when E@H gets out of
> beta. Will likely discard when Boinc has cache deadline check capability
> built in, or a problem shows up. So far so good.
>
Major disadvantage: If one of the projects has no work during its turn, no crunching will be done on any project.
> > Experiment to resolve cache deadline issue when running multiple projects
> > on one computer. Made separate directories for each project. Installed
> > BoincCLI in each and attached to just one project...
>
> Major disadvantage: If one of the projects has no work during its turn, no
> crunching will be done on any project.
>
"Any project" or did you mean "that project"? You missed the third sentence. The worst case is the project without wu's wouldn't get any work done. All other projects would run normally since Boinc is installed idependantly in each directory, as I mentioned. It might even be possible to work around this with a bash script but will leave that for later. Alternately, if you monitor your system fairly closely, you could easily change the cron schedule to avoid any projects without work. So far its working fine the way it is and I don't have any wu's in the cache that can't be completed before the deadline. Also, other computers not attached to the same projects are not effected by having a single cache setting. Maybe not for everyone but still interesting and educational.
We have enabled the BOINC configuration option 'enforce_delay_bound'. This prevents work from being sent to your machine if BOINC determines that your machine could not finish the work before the deadline. This may affect users with very slow machines, or users attached to multiple BOINC projects, whose Einstein@Home resource share is small."
> "Feb 13, 2005
>
> We have enabled the BOINC configuration option 'enforce_delay_bound'. This
> prevents work from being sent to your machine if BOINC determines that your
> machine could not finish the work before the deadline. This may affect users
> with very slow machines, or users attached to multiple BOINC projects, whose
> Einstein@Home resource share is small."
>
> Allright!
>
What is considered SMALL?? I allow all three projects to share equally.
My Current SETI WU's are scheduled to complete before Feb 22. My Einstein WU's are scheduled for the 16th. The SETI WU's complete 2 to every one Einstein WU. I know the science is different, but I would think that the Einstein WUs expiration should be either at the same time frame as the SETI WU's or after them.
Ran across this definition of resource share "When you join your second and subsequent projects this value and the value in the other project's preferences are totaled up and then used to create a proportion that indicates the amount of time to be allocated to that project." http://boinc-doc.net/site-common/oman-web/preferences-project-cah-view.php
Resource share controls time, so if you set the share too low, your computer won't have enough time to finish a wu for some project. What value that is depends on the speed of your machine, the deadline, and how many projects you are attached to. At least that's my take.
I guess 'enforce_delay_bound' must be enabled from the server side. Don't see it in the command line options http://boinc.berkeley.edu/client_unix.php unless it is a compile option?
>
> My Current SETI WU's are scheduled to complete before Feb 22. My Einstein WU's
> are scheduled for the 16th. The SETI WU's complete 2 to every one Einstein
> WU. I know the science is different, but I would think that the Einstein WUs
> expiration should be either at the same time frame as the SETI WU's or after
> them.
>
> Both sets WU's were downloaded the same day.
>
>
Einstein has chosen to use a deadline of 7 days. S@H has chosen to use a deadline of two weeks. This explains the difference you see in WUs downloaded the same day.
> I guess 'enforce_delay_bound' must be enabled from the server side. Don't see
> it in the command line options http://boinc.berkeley.edu/client_unix.php
> unless it is a compile option?
That is correct. That is a server side constraint. The intent is to better take into account other projects. Up to now, each project acted is splendid isolation from all other project.
Though there is a connection point between projects with the BOINC Manager on an individual's PC, this has not been used (as of yet) to make more intelligent decisions. It is not clear to me that the BOINC Developers see the need for better coordination, though it would be a smart thing to do as the fundamental point of BOINC is to be multi-project ...
After the cross-platform GUI goes live and in color, we may see that these kind of features being folded into the PC side of the system. As an example, I pointed out on the developers mailing list that with the ability of a BOINC Manager to connect to and control other local BOINC installations coupled with the ability to suspend and resume work units; we have all the needed tools to make the management and control of the work performed. This means that the desire to allocate resources to projects could be more effectively managed to implement the participant's desires.
Beneficial side effects of course include the possibility of the BOINC Manager being smarter about which work units are processed and to also make sure that none of them blow past their deadlines ....
> "What is considered SMALL??"
>
> Ran across this definition of resource share "When you join your second and
> subsequent projects this value and the value in the other project's
> preferences are totaled up and then used to create a proportion that indicates
> the amount of time to be allocated to that project."
> http://boinc-doc.net/site-common/oman-web/preferences-project-cah-view.php
> Resource share controls time, so if you set the share too low, your computer
> won't have enough time to finish a wu for some project. What value that is
> depends on the speed of your machine, the deadline, and how many projects you
> are attached to. At least that's my take.
>
> I guess 'enforce_delay_bound' must be enabled from the server side. Don't see
> it in the command line options http://boinc.berkeley.edu/client_unix.php
> unless it is a compile option?
Correct: enforce_delay_bound is a SERVER option. I should have enabled it three months ago, but didn't realize it was OFF by default.
This does the following. When the core client requests work from the scheduler, it also reports how many seconds of work it still needs to do. Before sending work, the scheduler asks if the sum of the execution time of this work and the amount of pending work on the host would give a projected finishing time after the deadline. If so, the work is not sent to the host.
To compute the expected execution time on the host, the scheduler takes into account the measured floating point speed of the host, plus the resource share given to the project, and the number of CPUS. Roughly speaking
I expect that in many cases, the problem we have been having is not that 'the deadlines are too short'. The problem is 'the scheduler sends more work to the host than the host can expect to finish before the deadline!'
> Einstein has chosen to use a deadline of 7 days. S@H has chosen to use a
> deadline of two weeks. This explains the difference you see in WUs downloaded
> the same day.
>
is 7 days actually reasonable for a 100cr WU? My home computers only run an average of 8hrs per day and I'm currently running 4 projects. This means it takes around 5 days, to complete a E@H WU on the faster computer. Add to this that you only report a previous WU after completing the next means all my WUs will be reported about 10 days after downloading.
my computers at home currently have a Sempron 2400 and an XP 2500. With such a short deadline and the caching limit, I think E@H may be cutting themselves short of a lot of available processing power
My Boinc 4.19 estimates that Einstein should run a WU in 8.5 hours roughly.
In reality it's taking just over 10.5 hours. Consequently, Boinc tends to take on more work than time available.
For the other projects I do, the actual run times have been quicker than Boinc's estimated time. I invariably always meet the deadline for these projects.
I'm forced to keep my cache limit to 1.5 days so that Einstein WUs are completed on time.
I'm running boinc 4.19 on windows xp sp2 with centrino intel.
Can anything be done about the estimated timings for Einstein or is just one of those things? Will the enforce_delay_bound option fix this?
> Experiment to resolve cache
)
> Experiment to resolve cache deadline issue when running multiple projects on
> one computer. Made separate directories for each project. Installed BoincCLI
> in each and attached to just one project, in my case just S@H and E@H. Used
> Webmin in my Linux system to create 3 cron jobs to turn projects on and off.
> To turn off each project just issed killall boinc_4.19_i686-pc-linux-gnu via
> cron. Killing Boinc also kills the project client which is a child process.
> So don't have to keep track of project client version number. Cron job
> wouldn't directly turn on the project(s) for some reason, got "another
> instance of BOINC running" error message (permissions/lockfile issue?), but
> top or ps didn't show anything running. So used a couple of short bash
> scripts #!/bin/sh, then cd /path to project directory/, then
> ./boinc_4.19_i686-pc-liux-gnu &. Made scripts executable. Then used cron
> to start each project via its bash script. Had to use two scripts because
> each project is in a separate directory.
>
> Setup has been running for two days without problems. Advantages are you have
> complete control of run time for each project, run S@H from 9am to 5:59pm and
> run E@H from 6pm to 8:59am when E@H is less likely to be interrupted. Have
> complete control of cache for each project so can adjust for deadline.
> Noticed if running multiple projects from a single Boinc client that the most
> recent cache setting migrates to all project webpages. Since I have other
> computers running only S@H these were effected also, so I can now keep the
> cache limit I want. Some disadvantages are that more manual overhead is
> involved in setting up the projects. If a project runs out of wu's Boinc now
> won't automatically switch over to aother project, but having independant
> control of the cache makes this less likely. System working in Linux, should
> also work on a recent Mac since nix based, don't know if Windows has a similar
> cron function. Will migrate to other computer systems when E@H gets out of
> beta. Will likely discard when Boinc has cache deadline check capability
> built in, or a problem shows up. So far so good.
>
Major disadvantage: If one of the projects has no work during its turn, no crunching will be done on any project.
BOINC WIKI
> > Experiment to resolve
)
> > Experiment to resolve cache deadline issue when running multiple projects
> > on one computer. Made separate directories for each project. Installed
> > BoincCLI in each and attached to just one project...
>
> Major disadvantage: If one of the projects has no work during its turn, no
> crunching will be done on any project.
>
"Any project" or did you mean "that project"? You missed the third sentence. The worst case is the project without wu's wouldn't get any work done. All other projects would run normally since Boinc is installed idependantly in each directory, as I mentioned. It might even be possible to work around this with a bash script but will leave that for later. Alternately, if you monitor your system fairly closely, you could easily change the cron schedule to avoid any projects without work. So far its working fine the way it is and I don't have any wu's in the cache that can't be completed before the deadline. Also, other computers not attached to the same projects are not effected by having a single cache setting. Maybe not for everyone but still interesting and educational.
"Feb 13, 2005 We have
)
"Feb 13, 2005
We have enabled the BOINC configuration option 'enforce_delay_bound'. This prevents work from being sent to your machine if BOINC determines that your machine could not finish the work before the deadline. This may affect users with very slow machines, or users attached to multiple BOINC projects, whose Einstein@Home resource share is small."
Allright!
> "Feb 13, 2005 > > We have
)
> "Feb 13, 2005
>
> We have enabled the BOINC configuration option 'enforce_delay_bound'. This
> prevents work from being sent to your machine if BOINC determines that your
> machine could not finish the work before the deadline. This may affect users
> with very slow machines, or users attached to multiple BOINC projects, whose
> Einstein@Home resource share is small."
>
> Allright!
>
What is considered SMALL?? I allow all three projects to share equally.
My Current SETI WU's are scheduled to complete before Feb 22. My Einstein WU's are scheduled for the 16th. The SETI WU's complete 2 to every one Einstein WU. I know the science is different, but I would think that the Einstein WUs expiration should be either at the same time frame as the SETI WU's or after them.
Both sets WU's were downloaded the same day.
"What is considered
)
"What is considered SMALL??"
Ran across this definition of resource share "When you join your second and subsequent projects this value and the value in the other project's preferences are totaled up and then used to create a proportion that indicates the amount of time to be allocated to that project."
http://boinc-doc.net/site-common/oman-web/preferences-project-cah-view.php
Resource share controls time, so if you set the share too low, your computer won't have enough time to finish a wu for some project. What value that is depends on the speed of your machine, the deadline, and how many projects you are attached to. At least that's my take.
I guess 'enforce_delay_bound' must be enabled from the server side. Don't see it in the command line options http://boinc.berkeley.edu/client_unix.php unless it is a compile option?
> > My Current SETI WU's are
)
>
> My Current SETI WU's are scheduled to complete before Feb 22. My Einstein WU's
> are scheduled for the 16th. The SETI WU's complete 2 to every one Einstein
> WU. I know the science is different, but I would think that the Einstein WUs
> expiration should be either at the same time frame as the SETI WU's or after
> them.
>
> Both sets WU's were downloaded the same day.
>
>
Einstein has chosen to use a deadline of 7 days. S@H has chosen to use a deadline of two weeks. This explains the difference you see in WUs downloaded the same day.
Seti Classic Final Total: 11446 WU.
> I guess
)
> I guess 'enforce_delay_bound' must be enabled from the server side. Don't see
> it in the command line options http://boinc.berkeley.edu/client_unix.php
> unless it is a compile option?
That is correct. That is a server side constraint. The intent is to better take into account other projects. Up to now, each project acted is splendid isolation from all other project.
Though there is a connection point between projects with the BOINC Manager on an individual's PC, this has not been used (as of yet) to make more intelligent decisions. It is not clear to me that the BOINC Developers see the need for better coordination, though it would be a smart thing to do as the fundamental point of BOINC is to be multi-project ...
After the cross-platform GUI goes live and in color, we may see that these kind of features being folded into the PC side of the system. As an example, I pointed out on the developers mailing list that with the ability of a BOINC Manager to connect to and control other local BOINC installations coupled with the ability to suspend and resume work units; we have all the needed tools to make the management and control of the work performed. This means that the desire to allocate resources to projects could be more effectively managed to implement the participant's desires.
Beneficial side effects of course include the possibility of the BOINC Manager being smarter about which work units are processed and to also make sure that none of them blow past their deadlines ....
> "What is considered
)
> "What is considered SMALL??"
>
> Ran across this definition of resource share "When you join your second and
> subsequent projects this value and the value in the other project's
> preferences are totaled up and then used to create a proportion that indicates
> the amount of time to be allocated to that project."
> http://boinc-doc.net/site-common/oman-web/preferences-project-cah-view.php
> Resource share controls time, so if you set the share too low, your computer
> won't have enough time to finish a wu for some project. What value that is
> depends on the speed of your machine, the deadline, and how many projects you
> are attached to. At least that's my take.
>
> I guess 'enforce_delay_bound' must be enabled from the server side. Don't see
> it in the command line options http://boinc.berkeley.edu/client_unix.php
> unless it is a compile option?
Correct: enforce_delay_bound is a SERVER option. I should have enabled it three months ago, but didn't realize it was OFF by default.
This does the following. When the core client requests work from the scheduler, it also reports how many seconds of work it still needs to do. Before sending work, the scheduler asks if the sum of the execution time of this work and the amount of pending work on the host would give a projected finishing time after the deadline. If so, the work is not sent to the host.
To compute the expected execution time on the host, the scheduler takes into account the measured floating point speed of the host, plus the resource share given to the project, and the number of CPUS. Roughly speaking
expected exec time = (WU FLOPS * seconds/FLOP)/(RESOURCE FRACTION * NUM_CPUS)
I expect that in many cases, the problem we have been having is not that 'the deadlines are too short'. The problem is 'the scheduler sends more work to the host than the host can expect to finish before the deadline!'
Cheers,
Bruce
Director, Einstein@Home
> Einstein has chosen to use
)
> Einstein has chosen to use a deadline of 7 days. S@H has chosen to use a
> deadline of two weeks. This explains the difference you see in WUs downloaded
> the same day.
>
is 7 days actually reasonable for a 100cr WU? My home computers only run an average of 8hrs per day and I'm currently running 4 projects. This means it takes around 5 days, to complete a E@H WU on the faster computer. Add to this that you only report a previous WU after completing the next means all my WUs will be reported about 10 days after downloading.
my computers at home currently have a Sempron 2400 and an XP 2500. With such a short deadline and the caching limit, I think E@H may be cutting themselves short of a lot of available processing power
My cache size is difficult to
)
My cache size is difficult to assess.
My Boinc 4.19 estimates that Einstein should run a WU in 8.5 hours roughly.
In reality it's taking just over 10.5 hours. Consequently, Boinc tends to take on more work than time available.
For the other projects I do, the actual run times have been quicker than Boinc's estimated time. I invariably always meet the deadline for these projects.
I'm forced to keep my cache limit to 1.5 days so that Einstein WUs are completed on time.
I'm running boinc 4.19 on windows xp sp2 with centrino intel.
Can anything be done about the estimated timings for Einstein or is just one of those things? Will the enforce_delay_bound option fix this?