BOINC Priorities

Paul D. Buck
Paul D. Buck
Joined: 17 Jan 05
Posts: 754
Credit: 5385205
RAC: 0

RE: RE: This is / was a

Message 90462 in response to message 90461

Quote:
Quote:
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.

That idea was also not well received.

Gerry Rough
Gerry Rough
Joined: 1 Mar 05
Posts: 102
Credit: 1847066
RAC: 0

RE: RE: My idea is

Message 90463 in response to message 90462

Quote:
Quote:
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?


(Click for detailed stats)

Paul D. Buck
Paul D. Buck
Joined: 17 Jan 05
Posts: 754
Credit: 5385205
RAC: 0

RE: RE: RE: My idea is

Message 90464 in response to message 90463

Quote:
Quote:
Quote:
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 ...

Dagorath
Dagorath
Joined: 22 Apr 06
Posts: 146
Credit: 226423
RAC: 0

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.

Dagorath
Dagorath
Joined: 22 Apr 06
Posts: 146
Credit: 226423
RAC: 0

RE: So, if CPDN downloads

Message 90466 in response to message 90464

Quote:
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.

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9352143
RAC: 0

RE: - We cannot let the

Message 90467 in response to message 90464

Quote:

- 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. ;-)

Alinator

Paul D. Buck
Paul D. Buck
Joined: 17 Jan 05
Posts: 754
Credit: 5385205
RAC: 0

RE: Buck, you've got the

Message 90468 in response to message 90466

Quote:
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.

Paul D. Buck
Paul D. Buck
Joined: 17 Jan 05
Posts: 754
Credit: 5385205
RAC: 0

RE: RE: - We cannot let

Message 90469 in response to message 90467

Quote:
Quote:

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

Dagorath
Dagorath
Joined: 22 Apr 06
Posts: 146
Credit: 226423
RAC: 0

RE: RE: Buck, you've got

Message 90470 in response to message 90468

Quote:
Quote:
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.

Your deliberate ad hominem attack noted.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686043226
RAC: 583814

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.