> After finally setting E@H to 1 day and leaving S@H at 5, the S@H cache on this
> computer dropped (from 4 down to 2) as expected but the E@H cache unexpectedly
> grew by one extra wu (from 3 to 4). H1_0050.9_0051.4_0.1_T02_Test, after
> completeing, hung at 100% and apparently killed the E@H client. BoincCC
> continued but it stopped switching between projects and no further progress
> was made in either E@H or S@H.
>
> After waiting about 1/2 day and seeing no change, I stopped then restarted
> BoinCC, neither project was running, and the wu above restarted from 0%
> although it was past the deadline. Boinc bash script also reporting cpu usage
> at 23h 48m for E@H and 16h 19m for S@H which doesn't seem to be correct. May
> in part be related to using the 2.6.8 kernel. At this point I reset E@H and
> currently have the 2 S@H wu's and just 1 new E@H wu which seems about right
> for a 1 day setting on this old machine running BoinCC 4.19 and E@H 4.73, S@H
> still at 4.02.
>
> Want to leave S@H with a larger cache since two other machines are only
> crunching S@H wu's and am anticipating some outages with the rumored killing
> off of S@H Classic and 100% migration to Boinc in the near future.
>
You only get one cache setting. It is the same for all projects. The last one that was set is propogated to all projects / hosts. This is true of all of the General settings.
> You only get one cache setting. It is the same for all projects. The last
> one that was set is propogated to all projects / hosts. This is true of all
> of the General settings.
>
Not quite, I think that if you look at General Preferences you can set your PCs as Home, Work, School, just like project preferences. So each group can have a seperate cache size. May take a while to work through though, and you might need to ensure that setting changes on all projects to which you are attached.
> > You only get one cache setting. It is the same for all projects. The
> last
> > one that was set is propogated to all projects / hosts. This is true of
> all
> > of the General settings.
> >
> Not quite, I think that if you look at General Preferences you can set your
> PCs as Home, Work, School, just like project preferences. So each group can
> have a seperate cache size. May take a while to work through though, and you
> might need to ensure that setting changes on all projects to which you are
> attached.
>
It is true that you get 3 groups to choose from (home/work/school), however, I believe that in 4.5x and later, each machine is allowed to be in exactly one group, so it is still the case that each machine has one cache size. I am not certain about this last because the discussion kept changing outcomes. But my response was to attempting to set one project one way, and another project a different way, and expecting a single computer to behave differently for the two projects.
> > I have Pirates set to 1000 and Einstein set to 50. They both request
> 8640
> > seconds of work on each connection.
>
> Well then I'm totally confused, because that's not what I see at all.
> Currently the only projects I have asking for work on my log are LHC and
> Pirates, so I'll use them as an example.
>
> Resource shares for 5 projects at 100/(5.71%), E@H at 250/(14.29%), and
> Pirates at 1,000/(57.14%). Connect to server every 3 days. CC is version
> 4.19.
>
> --- - 2005-01-29 20:40:26 - Insufficient work; requesting more
> LHC@home - 2005-01-29 20:40:26 - Requesting 27811 seconds of work
>
> --- - 2005-01-29 20:51:04 - May run out of work in 3.00 days; requesting more
> Pirates@Home - 2005-01-29 20:51:04 - Requesting 269484 seconds of work
>
> That's quite a huge difference in what they are requesting!
>
> In fact, just after joining E@H, I was adjusting resource shares because I
> didn't know what to expect from the project. (as well as just upgrading my CC
> from 4.13 to 4.15) I set all projects to an equal resource share, (100) with a
> "connect to server" of 1 day, I get 3-4 WUs in my queue on average from each
> project.
>
> When I set Pirates to 1000, I need to boost my "connect to server" to 3 days
> to get the same number of WUs (3-4) from each project. (Not a problem because
> Pirates rarely has work)
>
> If it's not looking at resource share, what would explain this?
Makes sense to me. Presumably you have LHC set to a resource share of 100, or at least had it there as that was the default. Since LHC is down, the resource sharing for it hasn't updated on your PC. So whatever you may hae asked it to be on the server, it's still stuck at 100 on your PC. Thus the LHC request is for around 10% of the Predictor WU request, as you in fact show.
> Makes sense to me. Presumably you have LHC set to a resource share of 100, or
> at least had it there as that was the default. Since LHC is down, the
> resource sharing for it hasn't updated on your PC. So whatever you may hae
> asked it to be on the server, it's still stuck at 100 on your PC. Thus the
> LHC request is for around 10% of the Predictor WU request, as you in fact
> show.
The resource share for LHC, BOINC beta, S@H, Predictor, and CPDN have always been 100 on my system. So the fact that the scheduler isn't updating isn't affecting what I'm seeing.
The point I was trying to get at, is that some are saying resource share isn't taken into account when the scheduler is giving out work. This is very obviously not the case from what I see. I can set a project and 1000 and it asks for significantly more work than the other projects. So I'm wondering why some see it, and some don't. Is it CC version or what? I know JM7 is running 4.6x or something. I'm just curious if it handles things differently.
> So I'm wondering why some see it, and some don't. Is it CC version or what? I know JM7 is running 4.6x or something. I'm just curious if it handles things differently.
>
On one computer setting resources allocates the amount of time each project is run . A higher resource project gets more time and its cache likely increases. The problem is that the BoincCC, any Boinc, does not look at the total cache to see if it can be completed before the deadline(s). The CC has the benchmark and other data but does not have the functionality to properly limit the cache taking deadlines into account. If you set the cache too large, boinc apparently uses the most recently updated cache setting for all projects, then you will always have wu's that cannot be completed before their deadline. Believe that it has been mentioned that this is a future goal.
On one computer, the only way around this I can see at the moment is to set up more than one directory. Say boince and boincs for E@H and S@H. Then, in linux anyway, set up cron jobs to start and stop the projects. Maybe run S@H from 9am to 7pm and run E@H from 7pm to 9am for example. You would get complete control of the resource share and could have different cache limits for each project. Anyone try this, will save me the experiment time when I get around to it :-)
> On one computer setting resources allocates the amount of time each project is
> run . A higher resource project gets more time and its cache likely
> increases.
Yes, I know what setting resources does. It's the "cache likely increases" that I'm curious about. There are some saying resource share doesn't affect the amount of work they get on their system. How could it be plainly obvious on some systems, (such as mine) yet apparently does nothing (other than affecting WU run times) on others? It makes no sense to me...
> The problem is that the BoincCC, any Boinc, does not look at the
> total cache to see if it can be completed before the deadline(s). The CC has
> the benchmark and other data but does not have the functionality to properly
> limit the cache taking deadlines into account. If you set the cache too
> large, boinc apparently uses the most recently updated cache setting for all
> projects, then you will always have wu's that cannot be completed before their
> deadline. Believe that it has been mentioned that this is a future goal.
Yes, I'm aware of this. This isn't what I'm talking about at all. I guess I'm not explaining myself very well...
> Yes, I know what setting resources does. It's the "cache likely increases"
> that I'm curious about. There are some saying resource share doesn't
Hit the enter key a little too quick. On my one testbed computer running two projects the resources only control time spend on each project. The most recently updated cache setting is used accross the board for both projects. The cache for each project doesn't see the other, they both use the most recently updated setting, which may make the total cache extend beyond the deadline(s). There, think I got it right this time. But then you can run projects independantly, on the same computer, to get around this as I mentioned. Haven't tried yet.
> Hit the enter key a little too quick. On my one testbed computer running two
> projects the resources only control time spend on each project. The most
> recently updated cache setting is used accross the board for both projects.
> The cache for each project doesn't see the other, they both use the most
> recently updated setting, which may make the total cache extend beyond the
> deadline(s). There, think I got it right this time. But then you can run
> projects independantly, on the same computer, to get around this as I
> mentioned. Haven't tried yet.
Yes, cache settings propagate to all projects you are attached to, and resource share is a per project setting. I'm not talking about the cache per se, but the resource shares effect on the cache. Nor am I talking about the resource shares effect on how long a particular project runs for.
Let me try again...
Some have brought up in this post (and others) that resource share doesn't influence the scheduler on their machines. I see something very different.
Using LHC and Pirates as a test bed is ideal right now because they aren't currently giving me any work and I have no WUs from them currently in my queue to influence the amount of work requested. (and each update will request work)
(Tests using CC ver. 4.19, with my current cache setting of 2 days)
Pirates resource share 50 - Updating project asks for 10,173 seconds of work.
Pirates resource share 100 - Project now asks for 19,156 seconds of work.
Pirates resource share 1000 - Project now asks for 93,045 seconds of work.
LHC resource share 50 - Updating project asks for 10,173 seconds of work.
LHC resource share 100 - Project now asks for 19,150 seconds of work.
LHC resource share 1000 - Project now asks for 93,013 seconds of work.
Resource share is indeed influencing the amount of work being requested by the scheduler. Both projects are asking for almost exactly the same amount of work with the same share, and both ask for more with a higher share.
So back to my original question. How come some are saying that resource share does not influence the scheduler? Apparently it works differently on various systems?
In a nutshell, is this a bug?
It seems to me if this is the case, yes, it can very definitely FUBAR how projects interact on some systems.
Hopefully I explained it well enough that people can follow me this time, otherwise, I give up...
> After finally setting E@H
)
> After finally setting E@H to 1 day and leaving S@H at 5, the S@H cache on this
> computer dropped (from 4 down to 2) as expected but the E@H cache unexpectedly
> grew by one extra wu (from 3 to 4). H1_0050.9_0051.4_0.1_T02_Test, after
> completeing, hung at 100% and apparently killed the E@H client. BoincCC
> continued but it stopped switching between projects and no further progress
> was made in either E@H or S@H.
>
> After waiting about 1/2 day and seeing no change, I stopped then restarted
> BoinCC, neither project was running, and the wu above restarted from 0%
> although it was past the deadline. Boinc bash script also reporting cpu usage
> at 23h 48m for E@H and 16h 19m for S@H which doesn't seem to be correct. May
> in part be related to using the 2.6.8 kernel. At this point I reset E@H and
> currently have the 2 S@H wu's and just 1 new E@H wu which seems about right
> for a 1 day setting on this old machine running BoinCC 4.19 and E@H 4.73, S@H
> still at 4.02.
>
> Want to leave S@H with a larger cache since two other machines are only
> crunching S@H wu's and am anticipating some outages with the rumored killing
> off of S@H Classic and 100% migration to Boinc in the near future.
>
You only get one cache setting. It is the same for all projects. The last one that was set is propogated to all projects / hosts. This is true of all of the General settings.
BOINC WIKI
> You only get one cache
)
> You only get one cache setting. It is the same for all projects. The last
> one that was set is propogated to all projects / hosts. This is true of all
> of the General settings.
>
Not quite, I think that if you look at General Preferences you can set your PCs as Home, Work, School, just like project preferences. So each group can have a seperate cache size. May take a while to work through though, and you might need to ensure that setting changes on all projects to which you are attached.
> > You only get one cache
)
> > You only get one cache setting. It is the same for all projects. The
> last
> > one that was set is propogated to all projects / hosts. This is true of
> all
> > of the General settings.
> >
> Not quite, I think that if you look at General Preferences you can set your
> PCs as Home, Work, School, just like project preferences. So each group can
> have a seperate cache size. May take a while to work through though, and you
> might need to ensure that setting changes on all projects to which you are
> attached.
>
It is true that you get 3 groups to choose from (home/work/school), however, I believe that in 4.5x and later, each machine is allowed to be in exactly one group, so it is still the case that each machine has one cache size. I am not certain about this last because the discussion kept changing outcomes. But my response was to attempting to set one project one way, and another project a different way, and expecting a single computer to behave differently for the two projects.
BOINC WIKI
Hmmm.... No comment on the
)
Hmmm.... No comment on the resource share? I'm really curious now.
> > I have Pirates set to
)
> > I have Pirates set to 1000 and Einstein set to 50. They both request
> 8640
> > seconds of work on each connection.
>
> Well then I'm totally confused, because that's not what I see at all.
> Currently the only projects I have asking for work on my log are LHC and
> Pirates, so I'll use them as an example.
>
> Resource shares for 5 projects at 100/(5.71%), E@H at 250/(14.29%), and
> Pirates at 1,000/(57.14%). Connect to server every 3 days. CC is version
> 4.19.
>
> --- - 2005-01-29 20:40:26 - Insufficient work; requesting more
> LHC@home - 2005-01-29 20:40:26 - Requesting 27811 seconds of work
>
> --- - 2005-01-29 20:51:04 - May run out of work in 3.00 days; requesting more
> Pirates@Home - 2005-01-29 20:51:04 - Requesting 269484 seconds of work
>
> That's quite a huge difference in what they are requesting!
>
> In fact, just after joining E@H, I was adjusting resource shares because I
> didn't know what to expect from the project. (as well as just upgrading my CC
> from 4.13 to 4.15) I set all projects to an equal resource share, (100) with a
> "connect to server" of 1 day, I get 3-4 WUs in my queue on average from each
> project.
>
> When I set Pirates to 1000, I need to boost my "connect to server" to 3 days
> to get the same number of WUs (3-4) from each project. (Not a problem because
> Pirates rarely has work)
>
> If it's not looking at resource share, what would explain this?
Makes sense to me. Presumably you have LHC set to a resource share of 100, or at least had it there as that was the default. Since LHC is down, the resource sharing for it hasn't updated on your PC. So whatever you may hae asked it to be on the server, it's still stuck at 100 on your PC. Thus the LHC request is for around 10% of the Predictor WU request, as you in fact show.
> Makes sense to me.
)
> Makes sense to me. Presumably you have LHC set to a resource share of 100, or
> at least had it there as that was the default. Since LHC is down, the
> resource sharing for it hasn't updated on your PC. So whatever you may hae
> asked it to be on the server, it's still stuck at 100 on your PC. Thus the
> LHC request is for around 10% of the Predictor WU request, as you in fact
> show.
The resource share for LHC, BOINC beta, S@H, Predictor, and CPDN have always been 100 on my system. So the fact that the scheduler isn't updating isn't affecting what I'm seeing.
The point I was trying to get at, is that some are saying resource share isn't taken into account when the scheduler is giving out work. This is very obviously not the case from what I see. I can set a project and 1000 and it asks for significantly more work than the other projects. So I'm wondering why some see it, and some don't. Is it CC version or what? I know JM7 is running 4.6x or something. I'm just curious if it handles things differently.
> So I'm wondering why some
)
> So I'm wondering why some see it, and some don't. Is it CC version or what? I know JM7 is running 4.6x or something. I'm just curious if it handles things differently.
>
On one computer setting resources allocates the amount of time each project is run . A higher resource project gets more time and its cache likely increases. The problem is that the BoincCC, any Boinc, does not look at the total cache to see if it can be completed before the deadline(s). The CC has the benchmark and other data but does not have the functionality to properly limit the cache taking deadlines into account. If you set the cache too large, boinc apparently uses the most recently updated cache setting for all projects, then you will always have wu's that cannot be completed before their deadline. Believe that it has been mentioned that this is a future goal.
On one computer, the only way around this I can see at the moment is to set up more than one directory. Say boince and boincs for E@H and S@H. Then, in linux anyway, set up cron jobs to start and stop the projects. Maybe run S@H from 9am to 7pm and run E@H from 7pm to 9am for example. You would get complete control of the resource share and could have different cache limits for each project. Anyone try this, will save me the experiment time when I get around to it :-)
> On one computer setting
)
> On one computer setting resources allocates the amount of time each project is
> run . A higher resource project gets more time and its cache likely
> increases.
Yes, I know what setting resources does. It's the "cache likely increases" that I'm curious about. There are some saying resource share doesn't affect the amount of work they get on their system. How could it be plainly obvious on some systems, (such as mine) yet apparently does nothing (other than affecting WU run times) on others? It makes no sense to me...
> The problem is that the BoincCC, any Boinc, does not look at the
> total cache to see if it can be completed before the deadline(s). The CC has
> the benchmark and other data but does not have the functionality to properly
> limit the cache taking deadlines into account. If you set the cache too
> large, boinc apparently uses the most recently updated cache setting for all
> projects, then you will always have wu's that cannot be completed before their
> deadline. Believe that it has been mentioned that this is a future goal.
Yes, I'm aware of this. This isn't what I'm talking about at all. I guess I'm not explaining myself very well...
> Yes, I know what setting
)
> Yes, I know what setting resources does. It's the "cache likely increases"
> that I'm curious about. There are some saying resource share doesn't
Hit the enter key a little too quick. On my one testbed computer running two projects the resources only control time spend on each project. The most recently updated cache setting is used accross the board for both projects. The cache for each project doesn't see the other, they both use the most recently updated setting, which may make the total cache extend beyond the deadline(s). There, think I got it right this time. But then you can run projects independantly, on the same computer, to get around this as I mentioned. Haven't tried yet.
> Hit the enter key a little
)
> Hit the enter key a little too quick. On my one testbed computer running two
> projects the resources only control time spend on each project. The most
> recently updated cache setting is used accross the board for both projects.
> The cache for each project doesn't see the other, they both use the most
> recently updated setting, which may make the total cache extend beyond the
> deadline(s). There, think I got it right this time. But then you can run
> projects independantly, on the same computer, to get around this as I
> mentioned. Haven't tried yet.
Yes, cache settings propagate to all projects you are attached to, and resource share is a per project setting. I'm not talking about the cache per se, but the resource shares effect on the cache. Nor am I talking about the resource shares effect on how long a particular project runs for.
Let me try again...
Some have brought up in this post (and others) that resource share doesn't influence the scheduler on their machines. I see something very different.
Using LHC and Pirates as a test bed is ideal right now because they aren't currently giving me any work and I have no WUs from them currently in my queue to influence the amount of work requested. (and each update will request work)
(Tests using CC ver. 4.19, with my current cache setting of 2 days)
Pirates resource share 50 - Updating project asks for 10,173 seconds of work.
Pirates resource share 100 - Project now asks for 19,156 seconds of work.
Pirates resource share 1000 - Project now asks for 93,045 seconds of work.
LHC resource share 50 - Updating project asks for 10,173 seconds of work.
LHC resource share 100 - Project now asks for 19,150 seconds of work.
LHC resource share 1000 - Project now asks for 93,013 seconds of work.
Resource share is indeed influencing the amount of work being requested by the scheduler. Both projects are asking for almost exactly the same amount of work with the same share, and both ask for more with a higher share.
So back to my original question. How come some are saying that resource share does not influence the scheduler? Apparently it works differently on various systems?
In a nutshell, is this a bug?
It seems to me if this is the case, yes, it can very definitely FUBAR how projects interact on some systems.
Hopefully I explained it well enough that people can follow me this time, otherwise, I give up...