Visiting the RTFM on "fetch minimal work", this option that can also be issued with boinccmd, seems to just fetch 1 task for 1 core and then exit the client when done.

--fetch_minimal_work
Fetch only 1 job per device (CPU, GPU). Used with --exit_when_idle, the client will process one job per device, then exit. New in 6.11

--//--

Why would anyone [iconized writes: I have only one 2600k, nice system."], want to run 1 task at the time on a multicore device with that option, when setting zero cache, and 1 core [x% of processors] achieves same?

--//--

Only when used with --exit_when_idle will it exit after the task is done. It doesn't say that you need to use --exit_when_idle, just that when you do so, that... etc.

---

Still, why would anyone with a 2600k engage in such a solution to avoid HP processing? Makes me think of that Gilbert O'Sullivan song.

--//--

The RTFM says "Fetch only 1 job per device (CPU, GPU)." If device and processor thread are synonymous, than that's new.

Keep humming

@Ageless,

Looked in the BFS if it maybe was worded differently, but did not find <fetch_minimal_work> on the cc_config.xml page or elsewhere in BFS. Hope this does not get blown with that 180 second minimum cache change just posted about in the alpha mail list. With the "Used with --exit_when_idle, the client will process one job per device, then exit", the device would never go idle.

--//--

The RTFM says "Fetch only 1 job per device (CPU, GPU)." If device and processor thread are synonymous, than that's new.

RTFM and FM being synonymous I suppose is new too? Try it for yourself.

And it's "then that's new" not "than that's new" unless you're in margaritaville.

Had already tried with a duo and 7.02 client. The client runs empty, and lets 1 core sit idle, then finishes last task and fetches ONE new task... just as the wiki describes, twice.

Keep humming.

--//--

OK, so you do grasp that after all work is done, only 1 job will be fetched for a multicore device? Try it... then it might get clearer.

Keep humming.

(good to see you still have that "then" and "than" compulsion going... something to work on)

--//--

If the scheduler waits until a core has no work to download more WUs then what is the real loss or damage? A few seconds lost time?

It's up to four hours, as a matter of fact.

Not a problem in my mind but if you really want the red button then submit a Trac ticket and ask for it.

I see no reason. You asked for example, there it is. OTOH, I think such feature being provided would make things even worse. OTOOH, the behaviour described in the example makes problem for me (although, I don't think it's a bug of any kind; It's just a way it is). As of my problem I'm going to solve it (and bunch of others); But excuse my arrogance, I'm going to do it my way.

I am in no position to grant or deny your request.

Good. Now admit that boinc doesn't need you to fight for it.

---

I'm counting for science,
points just make me sick.

Had already tried with a duo and 7.02 client. The client runs empty, and lets 1 core sit idle, then finishes last task and fetches ONE new task... just as the wiki describes, twice.

Yeah, I tested this now as well. It's worse even as it also ignores any GPU you have in the system. I am now running one task on my 4 core system (3 cores used, one reserved for the GPU) with GPU.

Reported that to Boinc_dev.

---

I think in theory the high priority function can suspend tasks and switch to others resulting that none of the tasks are finished before the deadline.

If that ever happens then you have valid reason to complain. At that point the suggestion will be to decrease your cache. In all the years I have being using BOINC I have never had a task miss a deadline. There are 2 reasons for that

Hello happy boincers and electricity taxpayers! (in case you would not have noticed the two go hand in hand)

I come in peace, so do not misinterpret my words if they seem staggered or irrelevant. Thus, english isn't my native language, so I hope to not make too much mistranslation...

I have carefully read the various responses and, as often, a convenient point raised by a user becomes a discussion of gurus level 2345, practicing the config file tuning!

As usual, in most discussions I have had in the forums, I am committed to (wrongly?) have the perspective of the non-"boinc user". One that uses the client because his neighbor told him it was "good". This person does not understand the computer; does not understand science projects for which it will put a computer available; ultimately, the boinc screen saver is "pretty". I'm sure you see what I mean. It is not derogatory or condescending, this is the case of many users.

So, I, who understand (almost all) what you explain, I'm still not agree with your expert explanations, which lead to dive into the configuration file. I agree with Iconized because me neither I do not understand why there is a high-priority mode.

Those who have never seen a wu going into high-priority mode on their client, I think it's because you have previously set up your configuration file and you have previously signed for projects that you know that they have a certain maturity and stability. Again, what you argue may be right, but not for the normal user.

The normal user does not modify its configuration file, the normal user will sign for simple projects which are "fun", not knowing at all what means "long-term debt" or "amount of work cache"...

So the normal user will sign for completely different project, with completely different WU duration, WU quantity or project maturity. Still, the normal user, because he has a today machine, will have a multi-cores processor and a correct memory amount.

Nevertheless, should the brilliant boinc's scheduler let plunder the resources made available? I don't think so...

I myself have 3 computers that work 24/7 and 3 others working in office hours. I GET ALL THE TIME HIGH PRIORITY UNITS! On the two types of computers. So come and tell that it will never happens when you know how to set your work cache is swollen! No offense.

I have great respect for the programmer of boinc's scheduler. I have much less respect for administrators of some projects, which I think, understood very well how one could turn to its advantage the stats and calculations made by the scheduler to switch to high priority.

Basically, look at the EON project, it has been 2 years that users are asking for longer deadlines, administrators do not care... I stopped to calculate for EON, the WU were ALWAYS in high priority... Just now, I receive a WU for Lattice which goes immediately in high priority: 29h45 to crunch before 29/12... This deadline is nonsense. It could make sense, if I only crunch for Lattice, which it's definitively not the case.

The respectable projects, those that work since a looooong time (Climate, Einstein, QMC, Docking, Enigma, etc) do not behave like that. Even if they have evolved, offered different types of calculation, different binaries, their WUs always come on time, correctly, regardless of the computer on which they run. And I think it's (almost) just because they know how to prepare a deadline!!!

So you can not think seriously about "how to fine tuning your configuration file" and completely ignore that there are bad project managers. Some are even unfair, since they (seems to) use the subtleties of the scheduler to their advantage.

I'm not in "conspiracy theory" mode, I am in a logic of common sense and a rational use of resources made ​​available by users.

I am convinced that there is also a "blinkers effect" (not sure of the term) because administrators do their computation tests on powerful computers with only their own project! Regardless that most users are involved in several projects on much less powerfull computers.

So as a conclusion: as a simple user, but an aware one, who have a look to its boinc clients from time to time, without the nose on it all day, who don't want to modify the config file, I would like to have a switch/option in menus to prevent high-priority mode.

If WU does not finish on time on my computers, it is because my computers are not powerful enough or not working hard enough (schedule time) and, hey: too bad for me and my stats. OR it's because this WU was not well prepared, rightly or wrongly, and, hey: so much for this (bad) project. But in both case, there is no need of a high priority mode, which can lead to spoil ressources for other projects.

Happy Christmas to all.

So as a conclusion: as a simple user, but an aware one, who have a look to its boinc clients from time to time, without the nose on it all day, who don't want to modify the config file, I would like to have a switch/option in menus to prevent high-priority mode.

If you do not look in BOINC all the time, then how do you know you get high-priority work all the time (as you claim to have in that same post)??
You do know that the high priority mode is just there to assure that work will get in by deadline?

When you see BOINC run your work in high-priority all the time, either:
- you're seen as a high-value user with very much trusted computers by the project who send you work with a very short deadline;
- or you've got too large a cache for all the projects you're attached to;
- or you've got too much work from one project whose deadline is very short;
- or you just added a project that BOINC hasn't a clue how long the tasks run for, whose estimate is way way way off and for which BOINC has to run some tasks to get a feel of how long these tasks run.

BOINC will always try to get work in by deadline. Essentially what happens when you switch off high-priority is that no work will ever try to be in by deadline again. The developers could just as well do away with the whole scheduler then, as what's the use when you get to decide what runs when for how long and for which amount of tasks? Why do you need BOINC?

P.S: For people wanting to learn a thing or two about BOINC, why not read its original whitepaper, or for this conversation local scheduling for Volunteer Computing. That way you may know why the developers chose to do things like this.

The client configuration file is only needed for advanced users. But no one on these forums can see from the outside whether you are one, so forgive if we ask you to use a certain setup that requires the client configuration file with certain debug or other flags that will help us help you.

---

If you do not look in BOINC all the time, then how do you know you get high-priority work all the time (as you claim to have in that same post)?

Sorry for the lack of precision in the use of the terms. I should rather have written:
I see SOME WUs or some project WUs going in high-priority mode ALL THE TIME.
It's not ALL the WUs, on ALL clients, ALL THE TIME.
The assertion is correct: I do not look at my clients all the time, but when I do, on the 6 hosts, there's always at least one WU in high priority.

The Lattice one I mentionned is still under computation in high-priority mode... My scheduler is set to swap projects every hour. The high-priority mode overload the swapping. This WU has taken time of other projects... In my point of view, it's wrong. That's all.

What's your response for Lattice when Einstein or QMC, for the same amount of time to crunch (~29h) give one week more?!!! They, do never go into high-priority...

When you see BOINC run your work in high-priority all the time, either:
- you're seen as a high-value user with very much trusted computers by the project who send you work with a very short deadline;
- or you've got too large a cache for all the projects you're attached to;

Some projects seem "being subscribed" to the high-priority mode...
If I refer to what you already pointed out to me many times in previous discussions: The WUs I see in high-priority aren't (seem not be) related to a cache problem... (If I well understand what you explain!!! ;-) ) They are (seem to be) related to too short deadlines and only a few projects produce that.

- or you just added a project that BOINC hasn't a clue how long the tasks run for, whose estimate is way way way off and for which BOINC has to run some tasks to get a feel of how long these tasks run.

Give time to a new project so that stats between the server and the scheduler are stabilized, of course! But if after 1 year, on different computers, a project continues to send ridiculously short deadlines, which in turn send WUs into high priority mode, I think it's also reasonable not to conclude by asking only TO THE USER to do something!

My long-term vision of this is to verify what happens when you do not touch anything! From this strict point of view, you can not always return to: check your cache of work etc. I insist: ON LONG TERM, some projects never go into high-priority mode. I have the same cache and scheduler parameters since 2007... Projects which tend to produce high-prioriy WUs are: newbies and dummies... You could not conclude that this is ONLY a matter of settings at client/user side.

It's precisely what I'm trying to point out: when healthy projects have stabilized the client performances, when healthy deadlines are calculated, there's no sign of high-priority on my clients...

- or you've got too much work from one project whose deadline is very short;

Indeed... So what's your response if the project administrators do not care with their ridiculously short deadlines? While other administrators do it well.

So, high priority is inherent to a fine scheduler. In no survey mode, to avoid projects with abusive deadlines which spoil time, the only solution is: do not sign in with this project. Ok.

Regards

---

But if after 1 year, on different computers, a project continues to send ridiculously short deadlines, which in turn send WUs into high priority mode, I think it's also reasonable not to conclude by asking only TO THE USER to do something!

You have a choice. Continue to run the project, or leave.
If there's plenty of projects out there that match your wish for a larger deadline, then why fight the couple that don't follow your rule?

Indeed... So what's your response if the project administrators do not care with their ridiculously short deadlines? While other administrators do it well.

What you do forget here is that there are scientists behind all the projects who expect results back. For some of the projects it doesn't matter that the results come back in 2 weeks time or more. But for others, more specifically the ones doing medicine research it is adamant that the results come back as soon as possible, not have them dilly-dally out there for 2 weeks or more.

Malariacontrol has a deadline of 3 days. Not much and it may make BOINC go into high priority even when you've been attached to that project for more than a year and let it allow to fetch work all that time. Even with a small cache Malaria can go into HP. But why worry about that?

What is it with the overwhelming need to tell BOINC what to work on next? Does the scheduler not follow the resource shares you set? Does your work not all meet the deadline? Why are you running BOINC, to help the science or to gain all those credits? Does it then matter where you get them from? Is someone forcing you to stay with the project(s) that in your eyes do things so damn wrong?

My BOINC is attached to 55 active projects, every month or so I change which projects can run for the next month. Some projects are on for ever, since their forums require a RAC above 0 to post.

At this time 9 projects are allowed to fetch work. I run BOINC 7.0.3, a test version with the whole new scheduler. It's set to a connect to of 0.1 days and cache of 0.5 days. Furthermore, BOINC only runs between the hours of 9pm and 7am when electricity is cheap (5pm and 7am in weekends). It will suspend all work when I start games, and off late I play a lot of TESV: Skyrim.

With all that baggage in check, you understand that my BOINC doesn't run much, but when it does run it will do so on 3 of the 4 CPU cores. I set one core free for everything else in my system. However, even with this whole new BOINC, with the whole new scheduler, with 9 projects fetching work, with all of the tests I do for the developers --both BOINC and the OpenCL developers at Albert-- and the gaming I have done for the past month, I have yet to see any project's tasks run in high-priority.

....

---