Server Status Page (SETI@Home)
From Unofficial BOINC Wiki
Contents |
[edit] General
The main purpose of this page will be to give you a comprehensive status of the BOINC Server-Side Daemon Programs and the Servers on which they run. The BOINC Server-Side Daemon Programs do their work in an endless cycle. As soon as one processing cycle is completed, they begin another.
The BOINC Server-Side Daemon Programs monitored include:
- Assimilator (not shown on SZTAKI Desktop Grid)
- BOINC Web Site (Data Driven Web Pages)
- Feeder Daemon
- File Deleter
- Scheduler
- Transitioner
- Validator (there may be more than one type of Validator, those Projects with more than one type of Work Unit will have one Validator for each unique type of Work Unit).
The Project specific BOINC Server-Side Daemon Program programs include:
- Einstein@Home
- Pulsar Work Generator (LHO) - (Work Generator Daemon)
- Pulsar Work Generator (LLO) - (Work Generator Daemon)
- SETI@Home Project
- BOINC Database
- Master Science Database
- Data Server - (Upload/Download Server)
- DB Purge
- Splitter - (Work Generator Daemon)
- SZTAKI Desktop Grid
- Master Program
To increase the visibility of the operational state of the various BOINC Powered Projects, the BOINC Web Site software has a standard page that shows the run state of the BOINC Server-Side Daemon Programs. The status indicators are color coded along with the "key word" indicating the specific operational state of that BOINC Server-Side Daemon Program.
The normal run states are:
- Running, shown on a green background.
- Stopped, shown on a red background.
- Disabled, shown on an orange background.
Not all of the BOINC Powered Projects use the "Disabled" state.
A BOINC Powered Project that has a very high work load may have multiple copies of one or more of the BOINC Daemons. If, temporarily, the demand is low, or maintenance needs to be performed, it is possible that the Project Team will not have all of the copies running at any one specific time.
The reasons that not all of the listed Servers and processes are in an "Running" status are many and varied. Some of those reasons include:
- The Project has capacity in reserve but the extra processing is not required as only one or two of the BOINC Server-Side Daemon Programs (assuming several copies of the BOINC Server-Side Daemon Programs exist) can keep up with the work load.
- For example, the Work Generators are not running. If there is a large collection of Work Units waiting to be issued, there is no need to create more. Each Work Unit that is pending issue takes up space, and if they have several weeks supply, why make more?
- The BOINC Server-Side Daemon Program or the Server went off-line due to a hardware or software problem.
- The BOINC Server-Side Daemon Program or the Server was taken off-line for maintenance, such as back-up, scheduled maintenance, disk de-fragmentation, etc. and the other BOINC Server-Side Daemon Programs and Servers are expected to be sufficient to handle the normal work load.
- The Project is over (and you never noticed until now?).
- Note:
- The page is updated with new data about every 10 minutes. I would imagine that this is a configurable parameter and that means that the actual refresh interval can change over time.
Other data may be displayed on the page. The additional data will be Project specific. The most common additional information that is displayed is a rough indication of the amount of work available and "in-flight".
[edit] Other Sources Of Server Status
If you belong to multiple BOINC Powered Projects, it can be a pain to try to look up all of the current status information. Most of the Team Web Sites will have a summary panel. This is also true of most of the "statistics sites".
There are also some third party monitors like the one that can be found at "BOINC Project Status".
[edit] Server Status Section
The main purpose of this page is to give you a comprehensive status of the back-end BOINC Server-Side Daemon Programs and the Servers on which they run. The BOINC Server-Side Daemon Programs do their work in an endless cycle. As soon as one processing cycle is completed, they begin another. Also, as you can see there are some of these BOINC Server-Side Daemon Program that have multiple copies, and in most cases the additional copies are run on a different Server. This allows the project to spread the processing load across several Servers.
In this first example, we can see that there are a fair number of BOINC Server-Side Daemon Programs and back-end server processes that we can monitor on this page, we can also see the basic status of the database and what is going on with the production of Work Units and the processing of Results.
In the first example we can see that this was taken when all of the servers and BOINC Server-Side Daemon Programs were up and running.
In the second example we can see that the page has several components in the down state. And no, they cannot take Prozac to change to an up status.
The reasons that not all of the listed servers and processes are many and varied. Some of those reasons include:
- The project has capacity in reserve but the extra processing is not required as only one or two of the daemons (assuming several copies of the BOINC Server-Side Daemon Programs) can keep up with the work load.
- The BOINC Server-Side Daemon Program or the server went off-line due to a hardware or software problem.
- The BOINC Server-Side Daemon Program or server was taken off-line for maintenance, such as back-up, scheduled maintenance, disk defragmentation, etc. and the other BOINC Server-Side Daemon Programs and servers are expected to be sufficient to handle the normal work load.
- The project is over and you never noticed until now?
- Note:
- The page is updated with new data about every 10 minutes. I would imagine that this is a configurable parameter and that means that the actual refresh interval can change over time.
- Ok, in this example all BOINC Server-Side Daemon Programs but one are running. And this is likely to be a fair representation of what the project will look like in most cases. Here we can see that one of the "Assimilators" is off.
[edit] Database Status Section
If you look at the "Database Status" portion of the page, you can see number of Work Units that are ready to be issued, how many are being processed by Participants, and how many are ready for the Validation Process or "transition".
The "Waiting for validation" count is of all of the Work Units for which there is a "need validate" flag set, and is therefore a correct count of how many Work Units are currently ready to be tested for validation but haven't been validated yet.
| State | Description |
|---|---|
| Results ready to send | For each Work Unit, there are 4 new Results that are generated that are then sent out to 4 individual Participant's Computers. |
| Results in progress | The number of Results issued to Participants who still haven't sent their individual Results back yet. |
| Work Units waiting for validation | A Work Unit gets Validated when enough Results are returned and their signals match. You don't validate singular Results - you validate a Work Unit's worth of Results. So when this queue was up to 1.25 million, that meant about 5 million Results were waiting on Credit (in other words, it was a lot worse than people thought).
Ok, some more information on how this works. If enough Participants have processed a Work Unit and there are enough "success" Results returned to be eligible for Validation, the Transitioner sets a "need validate" flag. After the Validator has checked this Work Unit's Results, it removes the "need validate" flag. The primary purpose of this number is to show if the Validator is keeping up or not with the Results as they are they are returned. It's not a count of how many "pending" Results have been created by the Participants at any one specific point in time. |
| Work Units waiting for assimilation | After a Work Unit is Validated (and it has a singular Canonical "correct" Result), this Result, which represents the Work Unit, is waiting to have its data input into the Master Science Database. |
| Work Units/Results waiting for deletion | After the Canonical Result representing the Work Unit is "assimilated", the original Work Unit Data File, and the multiple Result Data Files returned from the clients, are now waiting to be deleted. |
[edit] Splitter Status
In this section we can see the state of the production of the Work Units that will be issued to the Participants. Note that the selection of the tapes is semi-random and may include tapes from one or two years in the past. In general, the tapes are selected such that there is a lower likelihood of having large numbers of Work Units that are "noisy".
Picking tapes to split that are not close to each other in date is one of the means of doing this.
[edit] Web Addresses of the "Server Status" Page
| Project | URL | Server Status Documentation |
|---|---|---|
| Climateprediction.net (CPDN) | "Server Status" Page | None |
| Einstein@Home | "Server Status" Page | Server Status Page (Einstein@Home) |
| LHC@Home | None | |
| Rosetta@Home | Server Status Page (Rosetta@Home) | |
| SETI@Home | "Server Status" Page | Server Status Page (SETI@Home) |
| SIMAP@Home | "Server Status" Page | None |
| SZTAKI Desktop Grid | "Server Status" Page | Server Status Page (SZTAKI Desktop Grid) |
| World Community Grid | None | None |
Many of the Third Party Statistics Sites also show server status, see:
