Not downloading task, but in profile one in progress.

The first thing is not the consequence of the second.

How delete it from prof, to get a new task?

You can't delete it, but it doesn't matter, as the reason for not downloading new work is that there is no work to download at the moment.

Wait to deadline 12 jan?

Yes. If there will be work available in the meantime, your PC will download new work.

the deadline 2016-Jan-12 is over and the problem of getting no new tasks ist still not solved!!!

Everyone else is getting work, so this problem is *not* the project's fault.

Fr 29 Jan 2016 21:02:09 CET | GPUGRID | Not requesting tasks: don't need (CPU: job cache full; NVIDIA GPU: not highest priority project)

This line explicitly says that your BOINC manager does not request work. The project can't send work to a host which does not request it.

"NVIDIA GPU: not highest priority project" is definitely WRONG!!!

I had set the GPUGRID resources to 1000000 and all the other projects just to 1.
So GPUGRID has definitely the highest priority but my computers do not get new tasks independently how many times I request for new ones!

This is a very good observation, so there's no point in clicking on that button without changing some settings.

GET THAT PROBLEM FIXED!!!

Sure, but you've forgotten to say the magic word.

Otherwise GPUGRID will be dispunged!

Perhaps you've learned from Shakespeare to threaten the forum, but tell me how much loss would be a not working host for the project?
Your threatening is exactly that much serious.

To solve your problem:
I think your work buffer cache settings are inappropriate for the number of projects your host are attached to.
I would increase the work buffer, or reduce the number of CPU projects on that host.

You can also look here:
https://boinc.berkeley.edu/wiki/Client_configuration

... to turn on the work_fetch_debug option
... to look at some of the logic, in the Event Viewer, to determine why BOINC thinks GPUGrid is not the highest-priority GPU project on your host.

Hi Jacob,
many thanks for this hint!

My cc_config.xml looks like that:

<!--
This is a minimal configuration file cc_config.xml of the BOINC core client.
For a complete list of all available options and logging flags and their
meaning see: https://boinc.berkeley.edu/wiki/client_configuration
-->
<cc_config>
<log_flags>
<task>1</task>
<file_xfer>1</file_xfer>
<sched_ops>1</sched_ops>
</log_flags>
</cc_config>


If I interpret the configuration right I should edit it as follows:

<!--
This is a minimal configuration file cc_config.xml of the BOINC core client.
For a complete list of all available options and logging flags and their
meaning see: https://boinc.berkeley.edu/wiki/client_configuration
-->
<cc_config>
<log_flags>
<task>1</task>
<file_xfer>1</file_xfer>
<work_fetch_debug>1</work_fetch_debug> <---see this line
<sched_ops>1</sched_ops>
</log_flags>
</cc_config>

What should I change else?

Every help is welcome to get more tasks!

regards
Veit

Okay, so now restart BOINC, and see if the Event Log says something along the lines of:
1/31/2016 10:26:23 AM | | log flags: file_xfer, sched_ops, task, work_fetch_debug
... around the 3rd line.

Then, you can look at the details shown in the Event Log, to see the guts of what Work Fetch is calculating, when deciding what to do.

And, if you believe something didn't behave properly, you can report it. If you'd like, you could email me the Event Log lines that seem suspicious, and I can help you interpret what happened. I'll send you my email address in a Private Message.

Regards,
Jacob Klein

Hi Jacob,
I get a lot of messages:

So 31 Jan 2016 22:56:29 CET | | [work_fetch] target work buffer: 864000.00 + 864000.00 sec
So 31 Jan 2016 22:56:29 CET | | [work_fetch] --- project states ---
So 31 Jan 2016 22:56:29 CET | WUProp@Home | [work_fetch] REC 0.001 prio -0.000001 can't req work: non CPU intensive
So 31 Jan 2016 22:56:29 CET | Milkyway@Home | [work_fetch] REC 6.593 prio -0.001253 can req work
So 31 Jan 2016 22:56:29 CET | SETI@home | [work_fetch] REC 0.000 prio -0.013288 can req work
So 31 Jan 2016 22:56:29 CET | Albert@Home | [work_fetch] REC 461.612 prio -0.037942 can req work
So 31 Jan 2016 22:56:29 CET | Einstein@Home | [work_fetch] REC 5763.092 prio -0.490314 can req work
So 31 Jan 2016 22:56:29 CET | GPUGRID | [work_fetch] REC 6296.189 prio -0.509021 can req work
So 31 Jan 2016 22:56:29 CET | Collatz Conjecture | [work_fetch] REC 3707.924 prio -0.621823 can req work
So 31 Jan 2016 22:56:29 CET | PrimeGrid | [work_fetch] REC 70349.070 prio -5.706109 can req work
So 31 Jan 2016 22:56:29 CET | | [work_fetch] --- state for CPU ---
So 31 Jan 2016 22:56:29 CET | | [work_fetch] shortfall 2450042.84 nidle 0.00 saturated 1104595.60 busy 872931.55
So 31 Jan 2016 22:56:29 CET | | [work_fetch] sim used inst 0 sim excl inst 0
So 31 Jan 2016 22:56:29 CET | Milkyway@Home | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | SETI@home | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | Albert@Home | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | Einstein@Home | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | GPUGRID | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | Collatz Conjecture | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | PrimeGrid | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | | [work_fetch] --- state for NVIDIA GPU ---
So 31 Jan 2016 22:56:29 CET | | [work_fetch] shortfall 747556.56 nidle 0.00 saturated 980443.44 busy 889691.71
So 31 Jan 2016 22:56:29 CET | | [work_fetch] sim used inst 0 sim excl inst 0
So 31 Jan 2016 22:56:29 CET | Milkyway@Home | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | SETI@home | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | Albert@Home | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | Einstein@Home | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | GPUGRID | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | Collatz Conjecture | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | PrimeGrid | [work_fetch] fetch share 0.143
So 31 Jan 2016 22:56:29 CET | | [work_fetch] ------- end work fetch state -------
So 31 Jan 2016 22:56:29 CET | | [work_fetch] No project chosen for work fetch


But I do not know what they say.

Do you know more?

Please send me a PM so that we together can analyse the logs and to optimise BOINC.

But there is still one thing I criticise GPUGRID:
This is the only project which does not send enough tasks to build a buffer.
All other projects do so, so that there are all the time some tasks in the buffer.
Only GPUGRID sends tasks one by one!

Probably one time this could be better!

Regards
Veit

So 31 Jan 2016 22:56:29 CET | | [work_fetch] target work buffer: 864000.00 + 864000.00 sec

10+10 days is a very long buffer, as GPUGrid has a 5 days deadline, a 1 day +50% bonus and a 2 days +25% bonus.
GPUGrid gives at most 2 WU per GPU for a host, so there's no point in setting longer work buffer than the time it takes for your host to process 2 GPUGrid tasks.

So 31 Jan 2016 22:56:29 CET | | [work_fetch] --- project states ---
So 31 Jan 2016 22:56:29 CET | WUProp@Home | [work_fetch] REC 0.001 prio -0.000001 can't req work: non CPU intensive
So 31 Jan 2016 22:56:29 CET | Milkyway@Home | [work_fetch] REC 6.593 prio -0.001253 can req work
So 31 Jan 2016 22:56:29 CET | SETI@home | [work_fetch] REC 0.000 prio -0.013288 can req work
So 31 Jan 2016 22:56:29 CET | Albert@Home | [work_fetch] REC 461.612 prio -0.037942 can req work
So 31 Jan 2016 22:56:29 CET | Einstein@Home | [work_fetch] REC 5763.092 prio -0.490314 can req work
So 31 Jan 2016 22:56:29 CET | GPUGRID | [work_fetch] REC 6296.189 prio -0.509021 can req work
So 31 Jan 2016 22:56:29 CET | Collatz Conjecture | [work_fetch] REC 3707.924 prio -0.621823 can req work
So 31 Jan 2016 22:56:29 CET | PrimeGrid | [work_fetch] REC 70349.070 prio -5.706109 can req work

REC stands for Recent Estimated Credit. By default the BOINC manager takes a period of 10 days as a base for this estimation.
You can set a shorter period in the cc_config.xml file by using

<rec_half_life_days>X</rec_half_life_days>

I recommend to you to set the REC half life for 1 day, and check if it results in the desired behavior.
If not, then you should try a lager number, or a multiply of 10.
prio stands for "task requesting priority" (not the same as the "resource share" you set in the BOINC manager)
It is clear from the above list, that GPUGrid is not the highest priority according to the BOINC manager's calculation. The reason for that is GPUGrid gives very high credits for it's (long) tasks compared to other (GPU) projects which have to process much more workunits to achieve the same amount of credits (hence their larger priority).
If you want to focus on GPUGrid, it is advisable to have less GPU projects on the same host, or set the other project's resource share to 0. In this case the BOINC manager will request work from these projects when there's no work available from all of the non-0 resource share projects.
You can try to disable GPU tasks in your profile on other project's webpages in a venue created specially for GPUGrid hosts.
This "task requesting priority" calculation is not well documented, but it can mess up when there are many mixed (GPU-CPU) projects in the BOINC manager.

So ... now that you can read a little bit about the numbers BOINC has calculated (see below) ... now you can figure out why it chooses to ask a particular project for work, and how much it asks it, and also why it doesn't ask for work.

Here's some educational material (2 links), that although is outdated, should help a bit:
http://boinc.berkeley.edu/trac/wiki/ClientSched
http://boinc.berkeley.edu/trac/wiki/ClientSchedOctTen

Your settings are:

So 31 Jan 2016 22:56:29 CET | | [work_fetch] target work buffer: 864000.00 + 864000.00 sec

... 864000 = 10 days
... So you're asking "Always maintain at least 10 days of work, but if you're going to ask a project for work, ask to fill the buffer to 20 days."

Watch your CPU buffers:

So 31 Jan 2016 22:56:29 CET | | [work_fetch] --- state for CPU ---
So 31 Jan 2016 22:56:29 CET | | [work_fetch] shortfall 2450042.84 nidle 0.00 saturated 1104595.60 busy 872931.55

... We need 2450042.84 instance-seconds (28.3 instance-days) to completely fill the 20-day buffer for all CPUs
... There are 0 idle CPUs
... We are saturated with work for all CPUs, for 1104595.60 seconds (12.8 days)
... So, because 12.8 > 10, and no CPUs are idle, we don't need to ask for work.

Watch your NVIDIA buffers:

So 31 Jan 2016 22:56:29 CET | | [work_fetch] --- state for NVIDIA GPU ---
So 31 Jan 2016 22:56:29 CET | | [work_fetch] shortfall 747556.56 nidle 0.00 saturated 980443.44 busy 889691.71

... We need 747556.56 instance-seconds (8.65 instance-days) to completely fill the 20-day buffer for all NVIDIA GPUs
... There are 0 idle NVIDIA GPUs
... We are saturated with work for all NVIDIA GPUs, for 980443.44 seconds (11.34 days)
... So, because 11.34 > 10, and no NVIDIA GPUs are idle, we don't need to ask for work.

End result:

So 31 Jan 2016 22:56:29 CET | | [work_fetch] ------- end work fetch state -------
So 31 Jan 2016 22:56:29 CET | | [work_fetch] No project chosen for work fetch

... as expected.

If you find something misbehaving (note: not likely), then please send this type of Work Fetch debug, either to this thread, or privately to me. I basically helped David A optimize BOINC work fetch a while back, and I'd be highly interested in any misbehaving :)

Good luck!
Jacob

Hi Jacob,
thanks for analysing my logs!

As you wrote it is all OK.

I had set <rec_half_life_days>1.000</rec_half_life_days> as recommended.
Than I restarted BOINC-Manager and got this log:


Mo 01 Feb 2016 13:25:04 CET | | [work_fetch] ------- start work fetch state -------
Mo 01 Feb 2016 13:25:04 CET | | [work_fetch] target work buffer: 864000.00 + 864000.00 sec
Mo 01 Feb 2016 13:25:04 CET | | [work_fetch] --- project states ---
Mo 01 Feb 2016 13:25:04 CET | GPUGRID | [work_fetch] REC 6033.599 prio -0.000000 can't req work: "no new tasks" requested via Manager
Mo 01 Feb 2016 13:25:04 CET | WUProp@Home | [work_fetch] REC 0.001 prio -0.000000 can't req work: non CPU intensive
Mo 01 Feb 2016 13:25:04 CET | SETI@home | [work_fetch] REC 0.000 prio -0.014835 can't req work: "no new tasks" requested via Manager
Mo 01 Feb 2016 13:25:04 CET | Albert@Home | [work_fetch] REC 532.040 prio -1.000018 can req work
Mo 01 Feb 2016 13:25:04 CET | Collatz Conjecture | [work_fetch] REC 3558.731 prio -1.040383 can't req work: "no new tasks" requested via Manager
Mo 01 Feb 2016 13:25:04 CET | Milkyway@Home | [work_fetch] REC 361.362 prio -1.298211 can't req work: "no new tasks" requested via Manager
Mo 01 Feb 2016 13:25:04 CET | Einstein@Home | [work_fetch] REC 5522.736 prio -1.674122 can't req work: "no new tasks" requested via Manager
Mo 01 Feb 2016 13:25:04 CET | PrimeGrid | [work_fetch] REC 71694.715 prio -28.483848 can't req work: "no new tasks" requested via Manager
Mo 01 Feb 2016 13:25:04 CET | | [work_fetch] --- state for CPU ---
Mo 01 Feb 2016 13:25:04 CET | | [work_fetch] shortfall 2469575.55 nidle 0.00 saturated 1086337.31 busy 847216.38
Mo 01 Feb 2016 13:25:04 CET | | [work_fetch] sim used inst 0 sim excl inst 0
Mo 01 Feb 2016 13:25:04 CET | GPUGRID | [work_fetch] fetch share 0.000
Mo 01 Feb 2016 13:25:04 CET | SETI@home | [work_fetch] fetch share 0.000
Mo 01 Feb 2016 13:25:04 CET | Albert@Home | [work_fetch] fetch share 1.000
Mo 01 Feb 2016 13:25:04 CET | Collatz Conjecture | [work_fetch] fetch share 0.000
Mo 01 Feb 2016 13:25:04 CET | Milkyway@Home | [work_fetch] fetch share 0.000
Mo 01 Feb 2016 13:25:04 CET | Einstein@Home | [work_fetch] fetch share 0.000
Mo 01 Feb 2016 13:25:04 CET | PrimeGrid | [work_fetch] fetch share 0.000
Mo 01 Feb 2016 13:25:04 CET | | [work_fetch] --- state for NVIDIA GPU ---
Mo 01 Feb 2016 13:25:04 CET | | [work_fetch] shortfall 800777.57 nidle 0.00 saturated 927222.43 busy 904534.93
Mo 01 Feb 2016 13:25:04 CET | | [work_fetch] sim used inst 0 sim excl inst 0
Mo 01 Feb 2016 13:25:04 CET | GPUGRID | [work_fetch] fetch share 0.000
Mo 01 Feb 2016 13:25:04 CET | SETI@home | [work_fetch] fetch share 0.000
Mo 01 Feb 2016 13:25:04 CET | Albert@Home | [work_fetch] fetch share 1.000
Mo 01 Feb 2016 13:25:04 CET | Collatz Conjecture | [work_fetch] fetch share 0.000
Mo 01 Feb 2016 13:25:04 CET | Milkyway@Home | [work_fetch] fetch share 0.000
Mo 01 Feb 2016 13:25:04 CET | Einstein@Home | [work_fetch] fetch share 0.000
Mo 01 Feb 2016 13:25:04 CET | PrimeGrid | [work_fetch] fetch share 0.000
Mo 01 Feb 2016 13:25:04 CET | | [work_fetch] ------- end work fetch state -------
Mo 01 Feb 2016 13:25:04 CET | | [work_fetch] No project chosen for work fetch

Conclusion:
When my buffer is filled up and GPUGRID sends with the stated very conservative policy new tasks AND on the other hand ALL other projects send with a very aggressive policy new tasks at once finished tasks are uploaded, than I will never more get new tasks from GPUGRID!

VERY SAD!!!


Goodbye GPUGRID
Veit


PS: Will be the task sending policy of GPUGRID be changed one day?????

Veit:

1) You are aware that your most-recent log, shows that GPUGrid is set for "No New Tasks", right?
2) GPUGrid follows normal task scheduling, adhering to Resource Share and buffer rules as normal, with the exception of:
3) GPUGrid intentionally only allows work fetch requests to be given enough work such that there are no more than 2 tasks per GPU. They do this, because of 3 reasons: they require fast turnarounds, they want to allow you to begin work on a task while another one is being uploaded, and also because subsequent tasks sometimes depend upon the completion of prior tasks.

Don't be sad!

Just understand the rules, and work with them :) If you must leave, then too bad, but we tried to help. Personally, I hope you stay.

Regards,
Jacob Klein

Hi Jacob,

1) You are aware that your most-recent log, shows that GPUGrid is set for "No New Tasks", right?

yes, I stopped all but one project to see what will happen when fetching new tasks.
But there are still enough tasks in the buffer that I did not get new tasks yet.


Concerning your declaration of the rules of GPUGRID:
I understand the rules.
But I think my conclusions are right and with this policy I will never get new tasks from GPUGRID.

Do you interpret this fact in another way?

Regards
Veit

Well, sort of.

When BOINC decides that it is time for work fetch (ie: your cpu saturation is below your min_value of 10 days, or your gpu saturation is below your min_value of 10 days), if GPUGrid has the highest prio value (a value based on your REC and your Resource Shares)... then GPUGrid should be asked for work.

However, when asked, if your gpu "busy" value (a value indicative of work that must be run right now because it is already in jeopardy of missing deadline).. is sufficiently large, then you may not get new work, because the new work couldn't possibly start before the deadline of that new work. GPUGrid tasks generally have 5-day-deadlines. Hopefully that makes some sense. For instance, your last log showed a GPU busy value of "904534.93 secs" = 10.47 days ... so, even if work fetch asked GPUGrid for work, the project wouldn't give any, since they have 5-day-deadlines.

I'm not sure whether you'd get new work or not - but work fetch debug can help you to see what happened and why. It seems to me that you already have non-GPUGrid work that must run first in order to meet deadline, and that the "busy" non-GPUGrid work is already larger than 5 days worth.

Heck, sometimes GPUGrid is simply out of work to give - see their Server Status page.

You might consider lowering your buffers to something like "1 day / 1 day", or "2 days / 2 days", if that device is connected to the internet enough to not run out of work.

Less is more sometimes.

I am not getting new work since 2 days. Please provide guidance. Thanks. Laurent

No one is, they appear to have gone on their summer holiday.
Check the Server Status Link in the top right corner.

---

Hello! After a long hiatus, and a move, I am back.

In fact I got a newer computer, also crunching WorldCommunityGrid. In any case with the 1060 GTX 3 GB and an I7-7700. I should be able to do much better than with the GTX 770.

I haven't crunched in a while and settings have not changed that I know of...so why am I not getting new work? Server status shows WUs available.

Every time I try update in BOINC I get "communication deferred."

I don;t see any information about this on the forums.

Thank you in advance.

Hello! After a long hiatus, and a move, I am back.

In fact I got a newer computer, also crunching WorldCommunityGrid. In any case with the 1060 GTX 3 GB and an I7-7700. I should be able to do much better than with the GTX 770.

I haven't crunched in a while and settings have not changed that I know of...so why am I not getting new work? Server status shows WUs available.

Every time I try update in BOINC I get "communication deferred."

I don;t see any information about this on the forums.

Thank you in advance.

We can't see the characteristics of your GPU when we click on the characteristics of your computer.
Are you sure that your GPU is well recognized by your BOINC Manager?

---

[CSF] Thomas H.V. Dupont
Founder of the team CRUNCHERS SANS FRONTIERES 2.0
www.crunchersansfrontieres

In fact I got a newer computer, also crunching WorldCommunityGrid.

Are these tasks using your GPU?

In any case with the 1060 GTX 3 GB and an I7-7700. I should be able to do much better than with the GTX 770.

That's true, but your GPU doesn't show in the connfiguration of your host.

I haven't crunched in a while and settings have not changed that I know of...so why am I not getting new work? Server status shows WUs available.

Most probably you've installed BOINC manager as a service. In this case it can't detect and use your GPU. Check the event log of your BOINC manager after startup. If you see a message like "executing as a daemon" or "running as a daemon" then you should uninstall and reinstall BOINC (without checking the "service install" option) to fix this.

Every time I try update in BOINC I get "communication deferred."

That's only the end of the story, the reason why it's deferred can be found in the event log. You should see messages like
"GPUGRID | Requesting new tasks for CPU and NVIDIA GPU".
You should also check if you see your GPU listed in the first ~20 lines of the BOINC event log (after startup).

On my windows machine I'm getting new WUs, but not on my linux system. Is there any error or are no WUs available?

On this PC I'm not getting new work:

https://www.gpugrid.net/show_host_detail.php?hostid=182555