|BOINC master database||oscar||Disabled|
|BOINC replica database||carolyn||Disabled|
|SETI@home science database||paddym||Disabled|
|Astropulse science database||marvin||Disabled|
|data-driven web pages||muarae1||Disabled|
|download server 1||georgem||Running|
|download server 2||vader||Running|
||Program is operating normally|
||Program failed or ran out of work
(or the project is down)|
||Program has been disabled by staff
The database server is not accessible
: channels in progress
|(splitters are all currently offline)|
: completed channels
: channels with errors
(each file contains data for 14 channels)
Client Connection Statistics
For a periodically updated list of client types/versions that recently
connected to our servers, click here.
- BOINC master database: The mysql database that contains all BOINC related information
(user stats, forum messages, basic workunit/result information, etc.).
- BOINC replica database: A back-up server which contains an identical
copy of everything in the BOINC database. Read-only queries can be aimed at this
server to lessen the load on the BOINC database.
- SETI@home science database: The informix database that contains final science products
returned by SETI@home clients.
- Astropulse science database: The informix database that contains final science products
returned by Astropulse clients.
- data-driven web pages: Pages that require database access to be generated.
Pages like the forums, or ones that contain statistics or client version information, etc.
are occasionally turned off (by hand) when the database is down.
- upload/download server: Handles workunit/result transactions initiated by BOINC clients.
When a client requests a workunit, this server sends it out. When a client has
a result to send back, this server reads it and saves it to disk for later validation/assimilation/etc.
- scheduler: Determines what work is going to be sent to/received from requesting clients.
Clients go to the scheduler first to request work, and the scheduler tells the client what to get
and where to get it. If this is off, you cannot get any new work. After a client sends a result
back, it then contacts the scheduler which then marks it as received.
- feeder: Fills up the scheduler work queue with workunits ready to be sent.
The scheduler is usually too busy handling client transactions to maintain such a queue itself.
- transitioner: Handles state transitions of workunits and results.
Basically, the transitioners keep track of the results in progress
and makes sure they properly move down the pipeline. It is always asking the
questions: Is this workunit ready to send out? Has this result been received
yet? Is this a valid result? Can we delete it now?
- sah_validate/ap_validate: Validates SETI@home (or Astropulse) results by comparing them with similar
results returned by other users. If enough results for the same workunit have
been returned, the validator compares the data, deems one result from the set the
"canonical" result, and issues credit to all responsible users accordingly.
- sah_assimilator/ap_assimilator : Takes scientific data from validated results and
puts them in the SETI@home (or Astropulse) database for later analysis.
- mb_splitter/ap_splitter: Reads tapes (or tape images on disk) containing raw
telescope data and creates SETI@home (multi-beam) or Astropulse workunits for the BOINC/SETI@home clients.
At least one needs to be running to produce work, and that's usually enough.
- file_deleter: Deletes input/output files when no longer needed (i.e. after assimilation).
This program keeps our upload/download disks as empty as possible.
- db_purge: Deletes result/workunit records when no longer needed (i.e. after the associated
files have been deleted). Depending on server load, we usually wait 24 hours between the files have
been removed before purging the corresponding results so people can still view these results online
for a day after they've been processed/assimilated. This program keeps our BOINC database as small as possible
so that it fits in RAM (and therefore operates much faster).
- vote_monitor: A script which automates some aspects of forum moderation.
- ntpckr: This stands for Near Time Persistency Checker (we pronounce it "nitpicker").
A program that continually scans results as they are assimilated to see if they match
similar frequencies/sky positions/signal types/etc. with other results. The key to SETI is
finding similar presistent signals over multiple observations, which is what this program is
attempting to do in almost real time as data come in (i.e. "near time").
- rfi: This stands for Radio Frequency Interference - and works in conjunction
with the ntpckr. If a persistent signal is found, the rfi program checks to see if
any of the constituent signals are actually RFI from earth, and then rescore the
Database/file status states
- bruno: Intel Server (2 x 2.66GHz Xeon, 8 GB RAM)
- carolyn: Intel Server (2 x quad-core 2.4GHz Xeon, 96 GB RAM)
- centurion: Intel Server (2 x hexa-core 3.4GHz Xeon, 512 GB RAM)
- georgem: Intel Server (2 x hexa-core 3.07GHz Xeon, 96 GB RAM)
- khan: Intel Server (2 x 3.0GHz Xeon, 32 GB RAM)
- lando: Intel Server (2 x quad-core 2.4GHz Xeon, 12 GB RAM)
- marvin: Intel Server (2 x 2.66GHz Xeon, 16 GB RAM)
- oscar: Intel Server (2 x quad-core 2.4GHz Xeon, 96 GB RAM)
- paddym: Intel Server (2 x hexa-core 3.07GHz Xeon, 132 GB RAM)
- synergy: Intel Server (2 x hexa-core 2.53GHz Xeon, 96 GB RAM)
- muarae1: Intel Server (2 x hexa-core 3.07GHz Xeon, 76 GB RAM)
- muarae4: Intel Server (2 x hexa-core 3.07GHz Xeon, 76 GB RAM)
- thumper: Sun Fire X4500 (2 x dual-core 2.6GHz Opteron, 16 GB RAM)
- vader: Intel Server (2 x dual-core 3GHz Xeon, 32 GB RAM)
- Results ready to send: For each workunit, results are generated
that are then sent out to individual users to be executed.
This is the number of excess results ready to be sent out, i.e. a backlog
in case demand exceeds the current rate of creation.
- Results in progress: Number of results currently being processed by clients.
- Result turnaround time: The average "wall time," taken over the last hour, between
when a task was downloaded and its result was uploaded.
- Results returned and awaiting validation: Number of finished results that have been uploaded
to our servers, but their constituent workunit has yet to reach quorum (usually because the redundant
task is still being processed by another client). Note this is a fairly fuzzy number, and may be
largely inflated if any other queues (beyond validation) are backlogged.
- Workunits waiting for validation: The number of workunits that reached
quorum and are waiting to be validated.
- Workunits waiting for assimilation: The number of workunits waiting to
have data from their canonical task input into the master science database.
- Workunit/Files waiting for deletion: The number of files
which can be deleted from disk, as the workunit has been assimilated, and there is no
more use for it or its constituent results.
- Workunits/Results waiting for db purging: The number of workunits or results
which have been deleted from disk and, after a short grace period (currently 24 hours),
will be purged from the database. It is during this grace period that completed results can
still be viewed in your personal account pages. For safety, important information is written
to disk and archived before these rows are deleted.
- Transitioner backlog: Amount of time that the transitioner is behind (i.e.
the age of the oldest task in the database waiting to be transitioned to another