Effects of and escape from High Priority Mode
8 Jun 2020 19:36:30 UTC
Topic 222773
(moderation:
I transitioned one of my machines from GRP to GW work and imagined I'd do something useful by generating some comparison data on the way. I over-fetched GW tasks, and now am in High Priority Mode, a place I generally avoid.
I seek a little wisdom.
I have several hundred tasks and am currently running at 1X. To get to 2X the way I run (using Einstein site preferences) I need to download a new task, but I suspect that the condition of BOINC that has it running a task at high priority probably blocks work requests, so no new downloads.
Questions:
1. Does the existence of a High priority task (as displayed by BOINCTasks giving the status column for a task as "Running High P." ) in fact preclude work requests?
2. What is the condition under which the machine enters and exits the High Priority state?
I generally don't abort tasks, but in this case, I was caught unaware that the GW deadline is 7 days instead of the 14 days I'm used to on GRP, and I failed to anticipate my difficulty in escaping the High Priority state in order to move up from 1X to 2X multiplicity.
I had a carefully constructed plan to do matched sets of tasks across nearly the full range of the h1_1590.60_O2C02Cl4In0__O2MDFV2h_VelaJr1... tasks, but now I'm just hoping to preserve a remnant spaced across the range while aborting enough to escape my trap.
archae86 wrote:1. Does the
)
Anything but yes would be counterproductive so high priority should defiantly stop work fetch!
If you have sched_op_debug enabled then the event log might give a hint if that's true.
Boinc takes into account estimated total work cache, % of time Boinc is running, % of time work is allowed etc. or in other words all the parameters that determine how much work you have based on previous work done and the estimated amount of work in your cache.
I haven't tried this for a while but I think that if you want to go down the rabbit hole of trying to understand how Boinc makes it's decisions then enabling rr_simulation or rr_simdetail in cc_config.xml or in the Event Log options in Boinc manager might be a good place to start. ;)
rr_simulation flag in the log
)
rr_simulation flag in the log exposes how BOINC decides how to schedule work. The rr_simulation routine is actually heavily called within the scheduler code in the client modules. But the output is extremely dense and obtuse for the average user. But it definitely shows why BOINC makes its decisions.
Thanks for the advice on how
)
Thanks for the advice on how to see BOINC making decisions.
Happily, I aborted just enough tasks to get it running without any suspends and not in HP mode for one project update. So I'm in 2X, and out of my immediate problem, though losing valued portions of my experiment, and having committed the crime of aborting 134 tasks.
I learned how much the
)
I learned how much the rr_simulation routine is used in scheduling because of an issue I raised with using a max_concurrent statement along with a gpu_exclude statement. The issue was:
Client: fix job scheduling bug #2918
After reviewing the newly added code by DA, I saw that a ton of rr_simulation routine calls got used by DA in the cpu_sched.cpp and rr_sim.cpp modules to fix the starvation issue.
So the routine is actually widely used in every scheduler contact and not just as a flag in the Event Log.