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

---

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.

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.

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.

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.

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.

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.

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.