No new work- scheduler says unreliable?

There is good reasoning behind this work request. It is only done in case the project installs a GPU application from one day to the other, so people who have a GPU and want that project to work on their GPU will get work. It's just a simple check, nothing broken. It won't interfere with requesting CPU work either, all it does is look weird, nothing more.

Quote:

Quote:

There is good reasoning behind this work request. It is only done in case the project installs a GPU application from one day to the other, so people who have a GPU and want that project to work on their GPU will get work. It's just a simple check, nothing broken. It won't interfere with requesting CPU work either, all it does is look weird, nothing more.

Which I understand, but Einstein has not done any work now in 4 - 5 days.

I'm only just reading this thread for the first time so perhaps I'll try to cover some issues raised in your previous messages as well. Perhaps I'll be repeating stuff that others have covered previously, so sorry if any of this is no longer needed.

In your first message you were confusing large data files (for GW crunching) that the server was acknowledging, with GW tasks that you could see in Boinc Manager. These are two quite separate entities. The large data files are not tasks they are simply the data that potentially a large number of tasks will operate on. You may get hundreds of tasks over time that use the same set of data files. When the data is exhausted, the data files are thrown away (you will see 'delete' messages) and fresh data is downloaded. This is quite separate from downloading an actual task.

A task is simply a set of parameters to feed to the science app to tell it how to operate on a particular set of data files. Each task listed in Boinc Manager will have a frequency component to its name eg. ..._0866.75_... which will match that in a pair of large data files. However other data files on either side of this frequency will also be used in the crunching of the task. If you get a new task at the next frequency step, say ..._0866.80_..., it is possible that you may also need to download 2 more large data files at a somewhat higher frequency, say ..._0867.05_... perhaps.

With regard to the client errors you have been having - yes they were most likely due to the bug when using CPU throttling. No doubt you have resolved those errors by only using 1 CPU and setting throttling at 100%. I understand your concern about allowing your background tasks to run unhindered but have you actually tried using both CPUs and no throttling to see what happens? BOINC runs the science apps at idle (the lowest) priority so that they should give up the CPU the moment anything else needs to run. My experience is that BOINC is quite good at doing this so perhaps your background tasks would be quite OK without closing off a whole CPU to BOINC.

With regard to your final question as to why EAH is not getting work at the moment. You haven't told us about your resource shares but your current SAH/EAH RAC figures show 1502/147 which suggest something like a 90%/10% or even 95%/5% split. How you split your resources is entirely up to you but please realise that a heavily one-sided split like this is likely to lead to prolonged periods where the minor project will not have work - just as you are seeing. If Seti has an outage, BOINC is likely to overstock with EAH tasks which will probably invoke 'high priority' mode for those tasks when Seti again has work. Once the crisis is over and the EAH work is finished, BOINC is unlikely to allow more EAH work until the debt is repaid to Seti - unless another Seti outage comes along and spoils the party.

You basically have two choices - either accept that EAH will have periods of no work on board, or give EAH a somewhat higher share of the pie. Also, I've just noticed that you are using BOINC 6.6.36. Many people are reporting weird scheduling issues with 6.6.x and the mere fact that there are now newer versions (.37, .38, and reputedly .39) doesn't give a great deal of confidence that things are fixed yet. Unless you are wanting to run CUDA apps at Seti, I would be tempted to give the whole 6.6.x mess a big miss and revert to something like 6.4.7 perhaps.