Certain Projects Hijack Boinc

Message boards : Questions and problems : Certain Projects Hijack Boinc
Message board moderation

To post messages, you must log in.

AuthorMessage
jconthespot

Send message
Joined: 2 May 20
Posts: 1
Message 98286 - Posted: 2 May 2020, 19:56:16 UTC

Why do certain projects hijack Boinc? I noticed that certain projects will stop other WU already being processed and then run their WU. I would consider this very rude and have decided to not participate in these projects.
ID: 98286 · Report as offensive
Falconet

Send message
Joined: 3 Oct 10
Posts: 36
Portugal
Message 98289 - Posted: 2 May 2020, 21:17:32 UTC - in response to Message 98286.  
Last modified: 2 May 2020, 21:17:59 UTC

No hijack at all.
It's the BOINC Manager that simply decides it has to run those projects first because of deadlines, etc.
ID: 98289 · Report as offensive
Ian&Steve C.

Send message
Joined: 24 Dec 19
Posts: 164
United States
Message 98290 - Posted: 2 May 2020, 21:27:12 UTC - in response to Message 98289.  

The manager doesn’t decide anything. It’s just a GUI. The client is doing it all. But either way it’s BOINC doing it yes.
ID: 98290 · Report as offensive
Falconet

Send message
Joined: 3 Oct 10
Posts: 36
Portugal
Message 98291 - Posted: 2 May 2020, 21:28:07 UTC - in response to Message 98290.  

The manager doesn’t decide anything. It’s just a GUI. The client is doing it all. But either way it’s BOINC doing it yes.


Yes, I meant the client.
ID: 98291 · Report as offensive
Bryn Mawr
Help desk expert

Send message
Joined: 31 Dec 18
Posts: 163
United Kingdom
Message 98292 - Posted: 2 May 2020, 21:36:34 UTC - in response to Message 98286.  

Why do certain projects hijack Boinc? I noticed that certain projects will stop other WU already being processed and then run their WU. I would consider this very rude and have decided to not participate in these projects.


The main reason I’ve seen for this behaviour is the project %age setting. If a project has just been added or has had a slack period then the scheduler will give it preference to the extent of stopping other project in their tracks until it has caught up.

The time period over which the workload is integrated is configurable but defaults to about 5 days and it often takes a good couple of days to settle down.
ID: 98292 · Report as offensive
Gary Roberts

Send message
Joined: 7 Sep 05
Posts: 128
Australia
Message 98411 - Posted: 10 May 2020, 4:24:32 UTC - in response to Message 98292.  

The main reason I’ve seen for this behaviour is the project %age setting. If a project has just been added or has had a slack period then the scheduler will give ....
This thread has the title "Certain Projects Hijack Boinc". This is likely to attract others who are equally misinformed. Many think that a 'nasty' project, through its scheduler, can force extra work onto the client. I just wanted to make sure that such readers, seeing your use of the term "scheduler" will understand that the client makes these decisions, not the project's scheduler. The comments here are really directed at the general readership, attracted by the thread title, rather than yourself.

It's certainly true that the "project %age setting" - more properly known as 'resource share' - will affect how much time a given project is allocated by the BOINC client (the bit that runs on the user's machine). It's not the only reason. If a user considers that a project is running too frequently, the initial action should be to go to the project website and check that the setting for resource share is appropriate, and perhaps reduce it if necessary.

The problem is in the second sentence where the scheduler is mentioned. Whilst it's true that the client arranges (or schedules) the order in which work is done on the user machine, the "scheduler" is more likely to be interpreted by the user as that program running at the server end (not the client end) whose job is to respond to client requests for specific amounts of work. It just provides (if it can) the work requested by the client. It cannot have any effect or control on when the client decides to run that work. Of course, if the user has set too large a cache size and the client requests too much work, then the scheduler, being an obedient servant, will simply respond to exactly what is requested. It's then up to the client to process the work whilst meeting both the resource shares set by the user and the deadlines of the tasks allocated.

So that is the second important reason for why a "project hijack" claim might be being made. The work cache size might be too large for the client to be able to process the work in an orderly fashion, within the various deadlines. The client switches to high priority mode and concentrates on one project to the exclusion of others. The answer in this case is to reduce the size of the work cache, rather than to change the resource share.

So, in both situations, it's up to the user to check both resource share and work cache size if they believe that a particular project is "hijacking Boinc". Projects DON'T force extra non-requested work on clients.
Cheers,
Gary.
ID: 98411 · Report as offensive
Bryn Mawr
Help desk expert

Send message
Joined: 31 Dec 18
Posts: 163
United Kingdom
Message 98412 - Posted: 10 May 2020, 9:40:53 UTC - in response to Message 98411.  
Last modified: 10 May 2020, 9:41:43 UTC

The main reason I’ve seen for this behaviour is the project %age setting. If a project has just been added or has had a slack period then the scheduler will give ....
This thread has the title "Certain Projects Hijack Boinc". This is likely to attract others who are equally misinformed. Many think that a 'nasty' project, through its scheduler, can force extra work onto the client. I just wanted to make sure that such readers, seeing your use of the term "scheduler" will understand that the client makes these decisions, not the project's scheduler. The comments here are really directed at the general readership, attracted by the thread title, rather than yourself.

It's certainly true that the "project %age setting" - more properly known as 'resource share' - will affect how much time a given project is allocated by the BOINC client (the bit that runs on the user's machine). It's not the only reason. If a user considers that a project is running too frequently, the initial action should be to go to the project website and check that the setting for resource share is appropriate, and perhaps reduce it if necessary.

The problem is in the second sentence where the scheduler is mentioned. Whilst it's true that the client arranges (or schedules) the order in which work is done on the user machine, the "scheduler" is more likely to be interpreted by the user as that program running at the server end (not the client end) whose job is to respond to client requests for specific amounts of work. It just provides (if it can) the work requested by the client. It cannot have any effect or control on when the client decides to run that work. Of course, if the user has set too large a cache size and the client requests too much work, then the scheduler, being an obedient servant, will simply respond to exactly what is requested. It's then up to the client to process the work whilst meeting both the resource shares set by the user and the deadlines of the tasks allocated.

So that is the second important reason for why a "project hijack" claim might be being made. The work cache size might be too large for the client to be able to process the work in an orderly fashion, within the various deadlines. The client switches to high priority mode and concentrates on one project to the exclusion of others. The answer in this case is to reduce the size of the work cache, rather than to change the resource share.

So, in both situations, it's up to the user to check both resource share and work cache size if they believe that a particular project is "hijacking Boinc". Projects DON'T force extra non-requested work on clients.


I truly apologise if my misuse of terminology could confuse but my main point was in the second paragraph.

I was trying to point out the effects of :-

<rec_half_life_days>X</rec_half_life_days>
A project's scheduling priority is determined by its estimated credit in the last X days. Default is 10;


Where the client will integrate the estimated credit achieved by each project and, if a project has fallen behind its resource share, will prioritise that project, apparently to the exclusion of all others.

As I personally dislike this behaviour I have set this value down from 10 days to 1 day.
ID: 98412 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4598
United Kingdom
Message 98413 - Posted: 10 May 2020, 9:56:25 UTC - in response to Message 98412.  

As I personally dislike this behaviour I have set this value down from 10 days to 1 day.
I agree - I set mine down to one day many years ago.

But this is a - configurable - default value in BOINC. It is wrong to give the impression that it is a malicious action by any project or projects.
ID: 98413 · Report as offensive
Bryn Mawr
Help desk expert

Send message
Joined: 31 Dec 18
Posts: 163
United Kingdom
Message 98414 - Posted: 10 May 2020, 10:16:49 UTC - in response to Message 98413.  

As I personally dislike this behaviour I have set this value down from 10 days to 1 day.
I agree - I set mine down to one day many years ago.

But this is a - configurable - default value in BOINC. It is wrong to give the impression that it is a malicious action by any project or projects.


I would never, ever, suggest that it was malicious - the hijack title was not mine, I was trying to advise how the op could mitigate his perceived problem.
ID: 98414 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4598
United Kingdom
Message 98415 - Posted: 10 May 2020, 10:37:37 UTC - in response to Message 98414.  

As I personally dislike this behaviour I have set this value down from 10 days to 1 day.
I agree - I set mine down to one day many years ago.

But this is a - configurable - default value in BOINC. It is wrong to give the impression that it is a malicious action by any project or projects.
I would never, ever, suggest that it was malicious - the hijack title was not mine, I was trying to advise how the op could mitigate his perceived problem.
Understood and accepted. But we are stuck under that title until either the OP or a moderator changes it. We - collectively - need to debunk it.
ID: 98415 · Report as offensive
Jacob Klein
Volunteer tester
Help desk expert

Send message
Joined: 9 Nov 10
Posts: 63
United States
Message 98416 - Posted: 10 May 2020, 12:52:17 UTC - in response to Message 98415.  
Last modified: 10 May 2020, 12:55:29 UTC

Some projects have super short deadlines, and depending on your cache size, BOINC may run tasks from those projects ahead of other tasks.

The MindModeling project comes to mind. I've created a few forum posts about this issue on their forum, and at one point the admin said they made the deadlines a bit more reasonable, but then a new batch of work came along, and the deadlines were back to being due too quick for my tastes (like: Due in 12-36 hours).

Now, if this were interrupting my CPU work only, it would not be a problem for me. So long as my CPU threads are getting used, I'm happy, and Resource Share would "even things out" in the long term, such that MindModeling would only get its fair share of time of my CPUs.

But when I saw that these short deadline tasks make my GPUs go idle (because all CPUs were busy on "deadline-miss" "high-priority" "EDF" "earlist-deadline-first" MindModeling tasks) .... that was the last straw, for me. I do NOT want my GPUs to go idle.

So, a few years ago, I set the MindModeling project to "No New Tasks" on my 7 PCs, and was done with that.

So, there's an example where a project's configuration didn't jive well with how I wanted my resources to be distributed. And I took action to stop getting work from that project.
It was not a hijack. It was always the user's choice.
ID: 98416 · Report as offensive

Message boards : Questions and problems : Certain Projects Hijack Boinc

Copyright © 2021 University of California. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.