Transitioner Daemon
From Unofficial BOINC Wiki
[edit] General
The Transitioner Daemon handles the state transitions of Work Units and Results. Basically, the Transitioners keep track of the many, many Results in progress and makes sure they properly move down the pipeline. It is always asking the questions: Is this Work Unit ready to send out? Has this Result been received yet? Is this a Valid Result? Can we delete it now? Since there are always a large set of Results in progress, we need to run several Transitioners in tandem to keep up with the Work Unit/Result flow. The Waiting To Transition Queue tells you how many Work Units and Results are waiting to move down the pipeline. A large number means there is a problem somewhere in our BOINC Server System.
The Transitioner is a chunk of code (module) that "moves" the Results between phases as the state of the Result changes. So when the Work Unit is first issued, initial records are added to the Results Table in the BOINC Database, then as the Results come in, the Transitioner takes them and updates the status of the Result in the Results Table. Once a Quorum of Results has been created (by the Transitioner) the Canonical Result is chosen and ... bobs-your-uncle ... you are done.
Well, almost. Now the Canonical Result is processed by the Assimilator Daemon and this completes the process from Work Unit creation all the way through to the final output of the system. All that is left is to eliminate records in the BOINC Database that are no longer required (using the DB Purge Daemon along with removing the Work Unit Data Files and Result Data Files (using the File Deleter Daemon.
The Transitioner Daemons have many jobs:
- Generate target_nresults results for newly-added Work Units. For SETI@Home, this is three results for a newly-split Work Unit.
- Generate more Results if one or more reported as an Outcome of "client error", for Results not reported by the Result Deadline, failed Validation due to missing files, or failed Validation due to a Validate State of "no consensus yet".
- Setting "need_validate"-flag when at least min_quorum "success"-results reported, and when more "success"-results is reported for an already validated Work Unit or if already in the Validator Queue. For SETI@Home it is when there are at least two "success"-results.
- Trigger the Assimilator if Work Unit errored-out, either due to max_error_results or max_total_results.
- Trigger File Deleter when all Results are "done", and the Work Unit is Assimilated.
Normally the Transitioner Daemons have no problems keeping up, but example like now after an outage in SETI@Home the Transitioner Daemons is 8 hours backlogged. This means only now is Work Unit split 8 hours ago being made ready to be sent out to users. Also, it will take over 8 hours from a Work Unit have got min_quorum "success"-results before it's tried validated.
The Validator only looks at a Work Unit with "need_validate"-flag set, since the Transitioner Daemons is currently 8 hours backlogged the Validators have currently no problems keeping up, and the Validator Queue is therefore for the moment very short even many Work Unit have enough "success"-results.
Oh, and "Waiting for validation" is a count of how many Work Units or Results exist with the "need_validate"-flag set. It is not a count of how many "pending" Results there are currently pending. ;)
For successfully validated Work Units or if "success"-results is larger than max_success_results but still fails due to "no consensus yet", it's the Validator that triggers the Assimilator. For SETI@Home, this means if 6 "success"-results fails due to "no consensus yet".
