Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
World Community Grid Forums
Category: Support Forum: Community-maintained FAQs [authorized posting allowed] Thread: BOINC: High Priority / Earliest Deadline First (EDF) task processing. |
No member browsing this thread |
Thread Status: Active Total posts in this thread: 1
|
Author |
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Normally BOINC operates on a FIFO (First In First Out) basis, and takes into that equation the assigned time share (project weight) if multiple distributed computing grids are attached to a client and have work in the tasks queue. This time share is by default set to slices of 60 minutes ** per CPU thread. At times the client determines, that if it persists in this FIFO cycle, the risk is real that one or the other work unit will not complete in time. When BOINC determines this situation, it will put those tasks ahead of the queue, even pause tasks already running and process these in high priority mode. Reasons this condition develops are, to name some:
----------------------------------------1) Computer was off or broken for a longer time, 2) Task was suspended too long, 3) Tasks arrived with [very] short deadline or cache is greater than shortest deadline, 4) The additional buffer and or connect every xxx days setting is too high, 5) Estimated time of tasks in cache was increased substantially (is based on most recent completed task durations!), 6) The inter-project switch time was set high [intentionally] to force short deadline tasks ahead, 7) When a project share is set very small [e.g. WCG at 500 and other active project at 10], 8) When a backup project [at zero resource share] has work in queue [WCG servers were maybe down] and more. The idea is that if a condition of high priority processing develops [shows in BOINC Manager 'tasks' view, status column], to let BOINC run without interference [and maybe a few hours longer to catch up], because interference will make the situation more often worse than better. Whilst the term "Earliest Deadline First" or EDF is still commonly referred to in BOINC world, the actual named scheduling policy was abandoned in client versions above 5.7.4. If a client is not constantly micromanaged and no excessive buffering of work is allowed (rule of thumb, not above half the shortest deadline of any selected science project), the condition would very rarely occur, mostly only in the situation of point 5, above. Whilst the FIFO order of processing is how BOINC maintains sanity and balance across multiple client attached projects, some [exclusive WCG] volunteers like their work to process in an EDF order to automatically let any repair jobs or BETA test tasks ahead, which both have short deadlines (see related topic at end). When so desiring, some possible nasty caveats are in store if you choose to, then set the website device profile or local preferences option For clients 5.10 or earlier: "Switch between [DC Grids] applications every 60 minutes" to an interval time equal or longer than the regular shortest deadline. For instance: A 3 days deadline: Set to 4400 minutes minus [maximum] additional [work] buffer (cache) size A 4 days deadline: Set to 5800 minutes minus [maximum] additional [work] buffer (cache) size A 5 days deadline: Set to 7200 minutes minus [maximum] additional [work] buffer (cache) size For instance, the deadline is 4 days and the cache is 2 days. Set switch time to (rounded) 3000 minutes. This minimizes any undue panic for regular deadline tasks. For clients 6. and higher: As above, but project switch interval control no longer works. Instead, set the "Connect every ..." or "Minimum work buffer" (MinB], to a value at half of the shortest deadline. E.g. as at Sep. 2013, the WCG repair/no reply makeup jobs have the shortest deadline of 3 days. Set the MinB to 1.5 days and most always these rush jobs will skip to the front, suspending as many running jobs that have a longer deadline. Pitfalls are that if the additional buffer and or connect every xxx days is set too large in combination with the long switch times, the client will run near perpetually in a "High Priority" state. An upside is that these long switch times allows most all tasks to run to completion in 1 run, until other tasks get into deadline threat. Of course, to be sure that a client does operate according all preferences, local [disables *all* web operational preferences] or website device profile, set the Activity menu options "Run based on preferences" and "Network based on preferences". Given the many versions of BOINC being used by volunteers, it is not possible to give exact behaviors on a *per-version* basis. Enter your preferences, observe, tune and when happy, take the hands off and let BOINC do the job, really! When you do it gets the most work done. Notably, some clients that run in High Priority state on -all- cores/processors, will stop fetching work!. ** The switch time set [default 60 minutes] is -not- absolute. BOINC under normal FIFO state changes tasks (preempts) when a checkpoint is made by the science application aka saved the work unit progress. With this user settings forced switching (preempting) to shorter deadline tasks, it is recommended to also select the "Leave application in memory while suspended" aka LAIM ***, as else any progress not yet saved will be lost and at resume the task will start again at last checkpoint. *** LAIM is *not* recommended for devices with small memory [RAM] and running large memory requiring sciences. Intense disk swapping into virtual memory could develop! N.B. BOINC is a general purpose manager, not just designed for WCG, but to manage all projects attached to a client. Since projected remaining times to complete (TTC) are 'by approximation', often substantially off, the manager cannot assume that a job showing just few minutes remaining really will just need few minutes. Non-deterministic as many projects are in their nature of calculating the simulations [it could end in minutes, but also in hours or even days], priority of tasks [the nearest deadline in an EDF condition] overrules the TTC on tasks that are -not- under deadline threat. If these tasks are interrupted in between progress checkpoint saves, newer clients will hold interrupted tasks in memory for loss-less resume when it is their turn again [LAIM is automatic]. If short on memory [RAM], a smaller buffer setting is advised to prevent the EDF/High Priority condition. Related Topics: Deadlines for Standard & Rush Tasks and What Clients Get These Project Checkpoint Saving - How to Minimize Progress Loss on Close/Restart/Resume Return to the Start Here FAQ index
WCG Global & Research > Make Proposal Help: Start Here!
----------------------------------------Please help to make the Forums an enjoyable experience for All! [Edit 4 times, last edit by Former Member at Oct 5, 2013 9:31:46 AM] |
||
|
|