This is / was a topic of discussion on the Dev list also ... though the reception to the idea of giving the participants the ability to have a setting that they could use to cause the CPU scheduler to run tasks to completion on a project and possibly task level was not well received.
My idea is similar in that BOINC itself would prioritize the waiting work units before starting new ones. I generally agree with David Anderson on the issue of micromanagement, although I must admit that the lines are admittedly blurry at best. I am unwary as he is of buttons to accomplish the same result, but that is for others to debate.
My idea is similar in that BOINC itself would prioritize the waiting work units before starting new ones. I generally agree with David Anderson on the issue of micromanagement, although I must admit that the lines are admittedly blurry at best. I am unwary as he is of buttons to accomplish the same result, but that is for others to debate.
That idea was also not well received.
Did you mean the idea of BOINC itself prioritizing the WUs or the manual button idea for users?
My idea is similar in that BOINC itself would prioritize the waiting work units before starting new ones. I generally agree with David Anderson on the issue of micromanagement, although I must admit that the lines are admittedly blurry at best. I am unwary as he is of buttons to accomplish the same result, but that is for others to debate.
That idea was also not well received.
Did you mean the idea of BOINC itself prioritizing the WUs or the manual button idea for users?
That BOINC would prioritize and attempt to finish those tasks with 15 seconds to go rather than starting new tasks from the same project ...
This whole concept of micromanagement being bad, or giving participants more control over the way that BOINC acts is quite a farce. For example:
- We cannot let the participant have a setting that would allow them to say that BOINC should run tasks to completion as a default, but we can use the switch time to force the issue; even though this is worse because switch time is used in the calculations for work fetch and CPU scheduling. And when you use 12 hours as your switch time you seriously bias these calculations.
- We allow aborting of tasks and suspending of both tasks and projects, but won't allow the participant to direct BOINC manager to ask for and only allow one task from selected projects. So, if CPDN downloads 10 tasks it is considered "better" that I abort those tasks and increase the loads on the servers, rather than to prevent the waste in the first place.
Somehow the intelligent option is bad, while the stupider option is "better" because it prevents the participant from micromanagement ... except it doesn't ... it just means that the participant uses tactics that are worse for the system overall to get to the same ends ...
When the devs say this or that is a bad idea they quite often mean "we just don't have time to think of all the implications of coding that functionality, how it's going to affect all the other parts, etc."
Gerry, the fact that there are tasks sitting in your cache that were preempted with only 15 secs to go is insignificant in the grand scheme of things. The only adverse affect it has is that it bothers pedantic little neat freaks, the Felix Ungers of the world. The good thing about it is that watching the Felixes of the world moan and pine about nothing supplys comedic relief for the well adjusted. If they ever revive the Odd Couple serial this thread could surely inspire a storyline for 1 episode.
As I said in another thread... 200 chiefs thinking of code for 2 or 3 Indians to write.
So, if CPDN downloads 10 tasks it is considered "better" that I abort those tasks and increase the loads on the servers, rather than to prevent the waste in the first place.
That's precisely the kind of muddled thinking you support when you support the wasteful 5/3 policy at LHC@home.
Quote:
Somehow the intelligent option is bad, while the stupider option is "better" because it prevents the participant from micromanagement ... except it doesn't ... it just means that the participant uses tactics that are worse for the system overall to get to the same ends ...
Much the same applies to LHC@home. The intelligent option (the 3/3 scheme, shorter deadline and issuing resends to fast reliable hosts) is "stupid" while the stupid option (the 5/3 anachronism) is "better".
Buck, you've got the silly thinking you've always supported so why are you complaining about it? And I think I'm going to have to click the red X on your post because you are saying the BOINC devs are stupid... show some respect for goodness sake.
- We cannot let the participant have a setting that would allow them to say that BOINC should run tasks to completion as a default, but we can use the switch time to force the issue; even though this is worse because switch time is used in the calculations for work fetch and CPU scheduling. And when you use 12 hours as your switch time you seriously bias these calculations.
Wait a second, that is not strictly correct. The TSI does not have anything to do with calculating the size of work fetches, other than it sets the LTD trigger point where they are allowed. So if anything, a larger TSI will allow the host to fetch sooner when it is overworked.
The reason the CC switches away from a current task with little time remaining is typically because other projects have built up more positve STD than it has, or the new task has time pressure when the round robin simulator runs.
My personal expeience is that setting a TSI higher than default makes for better project variety and better efficiency overall, especially if you don't keep the tasks in memory when suspended.
I have big gun battleships on my private account, and where the occaisional switch away when almost done is kind of funky, I don't see where that has any really significant negative effect on the measured performance for them. As John has pointed out, some of the manual controls and policies changes proposed/implemented will result in blown deadlines for some right up to all work onboard if used improperly.
Of course, that doesn't mean the advanced user shouldn't have the kind of control being discussed. ;-)
Buck, you've got the silly thinking you've always supported so why are you complaining about it? And I think I'm going to have to click the red X on your post because you are saying the BOINC devs are stupid... show some respect for goodness sake.
Make us both happy and put me on your ignore list.
What I find amazing is that you cannot distinguish between a comment and a complaint.
- We cannot let the participant have a setting that would allow them to say that BOINC should run tasks to completion as a default, but we can use the switch time to force the issue; even though this is worse because switch time is used in the calculations for work fetch and CPU scheduling. And when you use 12 hours as your switch time you seriously bias these calculations.
Wait a second, that is not strictly correct. The TSI does not have anything to do with calculating the size of work fetches, other than it sets the LTD trigger point where they are allowed. So if anything, a larger TSI will allow the host to fetch sooner when it is overworked.
Actually, the bias seems to be to reduce the size of the cache and to force many tasks into High Priority Mode when they do not need to be based on the run time of the task and the deadline.
If needs be I can get the actual snippet of John's comment. But, my point was based on my Felix Unger monitoring of my work queue as it flexes about based on what the system has lined up to work on.
Buck, you've got the silly thinking you've always supported so why are you complaining about it? And I think I'm going to have to click the red X on your post because you are saying the BOINC devs are stupid... show some respect for goodness sake.
Make us both happy and put me on your ignore list.
Right back at ya, Buck.
Quote:
What I find amazing is that you cannot distinguish between a comment and a complaint.
RE: RE: This is / was a
)
That idea was also not well received.
RE: RE: My idea is
)
Did you mean the idea of BOINC itself prioritizing the WUs or the manual button idea for users?
(Click for detailed stats)
RE: RE: RE: My idea is
)
That BOINC would prioritize and attempt to finish those tasks with 15 seconds to go rather than starting new tasks from the same project ...
This whole concept of micromanagement being bad, or giving participants more control over the way that BOINC acts is quite a farce. For example:
- We cannot let the participant have a setting that would allow them to say that BOINC should run tasks to completion as a default, but we can use the switch time to force the issue; even though this is worse because switch time is used in the calculations for work fetch and CPU scheduling. And when you use 12 hours as your switch time you seriously bias these calculations.
- We allow aborting of tasks and suspending of both tasks and projects, but won't allow the participant to direct BOINC manager to ask for and only allow one task from selected projects. So, if CPDN downloads 10 tasks it is considered "better" that I abort those tasks and increase the loads on the servers, rather than to prevent the waste in the first place.
Somehow the intelligent option is bad, while the stupider option is "better" because it prevents the participant from micromanagement ... except it doesn't ... it just means that the participant uses tactics that are worse for the system overall to get to the same ends ...
When the devs say this or
)
When the devs say this or that is a bad idea they quite often mean "we just don't have time to think of all the implications of coding that functionality, how it's going to affect all the other parts, etc."
Gerry, the fact that there are tasks sitting in your cache that were preempted with only 15 secs to go is insignificant in the grand scheme of things. The only adverse affect it has is that it bothers pedantic little neat freaks, the Felix Ungers of the world. The good thing about it is that watching the Felixes of the world moan and pine about nothing supplys comedic relief for the well adjusted. If they ever revive the Odd Couple serial this thread could surely inspire a storyline for 1 episode.
As I said in another thread... 200 chiefs thinking of code for 2 or 3 Indians to write.
BOINC FAQ Service
Official BOINC wiki
Installing BOINC on Linux
RE: So, if CPDN downloads
)
That's precisely the kind of muddled thinking you support when you support the wasteful 5/3 policy at LHC@home.
Much the same applies to LHC@home. The intelligent option (the 3/3 scheme, shorter deadline and issuing resends to fast reliable hosts) is "stupid" while the stupid option (the 5/3 anachronism) is "better".
Buck, you've got the silly thinking you've always supported so why are you complaining about it? And I think I'm going to have to click the red X on your post because you are saying the BOINC devs are stupid... show some respect for goodness sake.
BOINC FAQ Service
Official BOINC wiki
Installing BOINC on Linux
RE: - We cannot let the
)
Wait a second, that is not strictly correct. The TSI does not have anything to do with calculating the size of work fetches, other than it sets the LTD trigger point where they are allowed. So if anything, a larger TSI will allow the host to fetch sooner when it is overworked.
The reason the CC switches away from a current task with little time remaining is typically because other projects have built up more positve STD than it has, or the new task has time pressure when the round robin simulator runs.
My personal expeience is that setting a TSI higher than default makes for better project variety and better efficiency overall, especially if you don't keep the tasks in memory when suspended.
I have big gun battleships on my private account, and where the occaisional switch away when almost done is kind of funky, I don't see where that has any really significant negative effect on the measured performance for them. As John has pointed out, some of the manual controls and policies changes proposed/implemented will result in blown deadlines for some right up to all work onboard if used improperly.
Of course, that doesn't mean the advanced user shouldn't have the kind of control being discussed. ;-)
Alinator
RE: Buck, you've got the
)
Make us both happy and put me on your ignore list.
What I find amazing is that you cannot distinguish between a comment and a complaint.
RE: RE: - We cannot let
)
Actually, the bias seems to be to reduce the size of the cache and to force many tasks into High Priority Mode when they do not need to be based on the run time of the task and the deadline.
If needs be I can get the actual snippet of John's comment. But, my point was based on my Felix Unger monitoring of my work queue as it flexes about based on what the system has lined up to work on.
RE: RE: Buck, you've got
)
Right back at ya, Buck.
Your deliberate ad hominem attack noted.
BOINC FAQ Service
Official BOINC wiki
Installing BOINC on Linux
Please let us keep this
)
Please let us keep this discussion technical instead of personal.
Anyway I wonder whether the E@H forum is the right place for this anyway.
CU
Bikeman