Server status

Database/file status

Splitter status

Client Connection Statistics

For a periodically updated list of client types/versions that recently connected to our servers, click here.

Glossary

Programs:

• 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 signals accordingly.

• 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 state).