I was referring to my previous post - my attempt to analyse which manifestation of 'priority' each of you were referring to.

I think Michael is referring to process priority on the CPU (aka 'niceness' in Linux).

I think mmonnin is referring to BOINC scheduling priority (aka 'Earliest Deadline First').

Hi Richard yes in that case DHE tasks would get the lowest priority compared to other BOINC projects as they have the latest deadline...

Hi Richard yes in that case DHE tasks would get the lowest priority compared to other BOINC projects as they have the latest deadline...

Not necessarily so. The question BOINC asks is:

Can this task be completed by its own deadline?

That depends on so many external factors: how 'big' the task is (fpops_est); how fast the machine is; what proportion of the time BOINC is active; resource share of your project; resource share of other projects; amount of work cached; etc.; etc.

You cannot know what the scheduling priority of your tasks might be on any given computer unless you know the complete state of every project being run on that machine: as BOINC does.

OK, I grabbed a task, and here's your proof.

30/06/2018 19:36:59 | | [cpu_sched_debug] schedule_cpus(): start
30/06/2018 19:36:59 | SETI@home | [cpu_sched_debug] reserving 1.000000 of coproc NVIDIA
30/06/2018 19:36:59 | SETI@home | [cpu_sched_debug] add to run list: blc06_2bit_guppi_58185_75400_Dw1_0032.18983.409.21.44.90.vlar_0 (NVIDIA GPU, FIFO) (prio -1.995557)
30/06/2018 19:36:59 | Distributed Hardware Evolution Project | [cpu_sched_debug] add to run list: wepiK1UBwsvMfnx44_0 (CPU, EDF) (prio -0.000509)
30/06/2018 19:36:59 | NumberFields@home | [cpu_sched_debug] add to run list: wu_septics_Bnd200E6_Grp2313443of3001592_0 (CPU, FIFO) (prio -0.104392)
30/06/2018 19:36:59 | NumberFields@home | [cpu_sched_debug] add to run list: wu_septics_Bnd200E6_Grp2308633of3001592_1 (CPU, FIFO) (prio -0.105225)
30/06/2018 19:36:59 | NumberFields@home | [cpu_sched_debug] add to run list: wu_septics_Bnd200E6_Grp2316040of3001592_0 (CPU, FIFO) (prio -0.106059)

And in BOINC Manager:


That's 14 days of work, to be completed in 7 days. Immediate EDF, as surmised - the deadline is impossible on any machine (and this is my newest, fastest, i5)

Please be prepared to consider factual evidence like this when you you wander into an environment where people really do know what they're talking about.

I aborted the task after the first trickle - http://dhep.ga/boinc/result.php?resultid=154497

You're writing an awful lot to stderr_txt - it's already overflowed after the first 15 minutes of your 328 hour run. BOINC only reports the last 64KB - I hope there was nothing important at the beginning.

That's 14 days of work, to be completed in 7 days. Immediate EDF, as surmised - the deadline is impossible on any machine (and this is my newest, fastest, i5)

OK good. Thanks Richard. Apologies I thought 'deadline' was related to the 'bound' which we set to four weeks. Now this is making more sense. However our task "bound" in the input template - ie. rsc_fpops_bound - is set to be four weeks which is far greater than the two weeks estimate allowing completion comfortably.

So where is this deadline coming from and how can we increase it? We haven't explicitly set any. Neither https://boinc.berkeley.edu/trac/wiki/ProjectOptions#Jobscheduling nor https://boinc.berkeley.edu/trac/wiki/ClientSched nor https://boinc.berkeley.edu/trac/wiki/JobTemplates shed much light on this. Is it a default? Or is BOINC somehow generating this figure?

Regarding stderr yes there is some temporary belts & braces tracking and overall output will be reduced dramatically soon.

https://boinc.berkeley.edu/trac/wiki/JobSubmission#creatework-tool
--delay_bound x

From https://boinc.berkeley.edu/trac/wiki/BackendState

Result state variables
report_deadline

Give up on result (and possibly delete input files) if don't get reply by this time.

    Set by scheduler to now + wu.delay_bound when send result. 

Time is in seconds, default is one week.

---

https://boinc.berkeley.edu/trac/wiki/JobSubmission#creatework-tool --delay_bound x

Awesome thanks Ageless that other (delay) bound did the trick.

From https://boinc.berkeley.edu/trac/wiki/BackendState.

Hmm.. never came across that wiki!.. perhaps it's only accessible from another.. not on the main list (https://boinc.berkeley.edu/trac/wiki/ProjectMain). I can see why that might be though..

Thanks again. Nearly there.

Hmm.. never came across that wiki!.. perhaps it's only accessible from another.. not on the main list (https://boinc.berkeley.edu/trac/wiki/ProjectMain).

It is, actually. In the section https://boinc.berkeley.edu/trac/wiki/ProjectMain#Submittingandhandlingjobs, about five lines down: "Submitting jobs locally".

There's a huge amount of (pretty dense) detail in there: it'll be worth getting familiar with it before you go live, in case users suggest you implement features you haven't found yet.

Or did you mean BackendState? Now you mention it, I can't find that link either.

Yes I did mean BackEndState. Was looking mainly in the "Computing with BOINC" Wikis as this is what I'm doing, but I suppose no harm in taking in the whole of "BOINC Software Development" ...

I figured it tout by going to https://boinc.berkeley.edu/trac/wiki/JobTemplates (which you gave), then clicking on the create_work() link. This gives the list of commands to give when making work. The only thing sounding like it referenced deadline was --delay_bound
Then doing a search for delay_bound gives a lot of options, I just picked the one with the best on-page description of what it did.

I long ago stopped wondering why BOINC uses two or more attribute & object names for one single value. :)

I long ago stopped wondering why BOINC uses two or more attribute & object names for one single value. :)

:)