Server status page


SETI@home server status information is also available in XML.

[As of 12 Feb 2012 | 17:30:05 UTC]

Server status

ProgramHostStatus
BOINC master databasecarolynRunning
BOINC replica databasejocelynRunning
SETI@home science databaseoscarRunning
Astropulse science databasemarvinRunning
data-driven web pagesthinmanRunning
scheduling serverbaneRunning
scheduler processbaneRunning
download server 1anakinRunning
download server 2vaderRunning
upload serverbrunoRunning
feeder.x86_64baneRunning
file_deleter1brunoRunning
file_deleter2brunoRunning
file_deleter3brunoRunning
file_deleter4vaderRunning
file_deleter5vaderRunning
file_deleter6vaderRunning
db_purge.x86_64vaderRunning
transitioner1synergyRunning
transitioner2synergyRunning
transitioner3synergyRunning
transitioner4synergyRunning
transitioner5synergyRunning
transitioner6synergyRunning
vote_monitorbrunoRunning
sah_validate1brunoRunning
sah_validate2brunoRunning
sah_validate3brunoRunning
sah_validate4brunoRunning
ap_validate1synergyRunning
ap_validate2synergyRunning
ap_validate3synergyRunning
ap_assimilator1synergyDisabled
ap_assimilator2synergyRunning
ap_assimilator3synergyRunning
ap_assimilator4synergyRunning
ap_assimilator5synergyRunning
ap_assimilator6synergyRunning
fix_ap_assimilator1synergyRunning
sah_assimilator1vaderRunning
sah_assimilator2vaderRunning
sah_assimilator3vaderRunning
sah_assimilator4vaderRunning
ap_splitter1synergyRunning
ap_splitter2landoNot Running
ap_splitter3landoNot Running
ap_splitter4synergyRunning
ap_splitter5synergyRunning
ap_splitter6synergyRunning
mb_splitter6landoRunning
mb_splitter7landoRunning
mb_splitter10synergyRunning
mb_splitter11synergyRunning
mb_splitter12synergyRunning
ntpckr_small_sig1synergyNot Running
ntpckr_small_sig2synergyNot Running
ntpckr_small_sig3synergyNot Running
ntpckr_small_sig4synergyNot Running
rfi1_small_sigsynergyDisabled
rfi2_small_sigsynergyDisabled
rfi3_small_sigsynergyDisabled
rfi4_small_sigsynergyDisabled
Running: Program is operating normally
Not Running: Program failed or ran out of work
(or the project is down)
Disabled: Program has been disabled by staff
(for debugging/maintenance)

Database/file status

BOINC Database Engine State#As of*
Master database queries/second  7570m
Replica seconds behind master  00m
 
Data Distribution StateSETI@home #Astropulse #As of*
Results ready to send207,36640m
Current result creation rate0.8261/sec0.8395/sec6m
Results out in the field4,623,08078,4250m
Results received in last hour70,6816640m
Result turnaround time (last hour average)45.99 hours119.42 hours0m
Results returned and awaiting validation3,421,32382,8720m
Workunits waiting for validation1900m
Workunits waiting for assimilation4700m
Workunit files waiting for deletion2400m
Result files waiting for deletion4000m
Workunits waiting for db purging833,6328,8190m
Results waiting for db purging1,736,68529,0750m
Transitioner backlog (hours)  00m
* minutes (m) or hours (h) since last checked

Splitter status

File nameSizeProgress
   Multibeam    Astropulse  
01oc11ae50.07 GB (14)
05oc11ak50.20 GB (3)
07oc11af50.20 GB (14) (done)
12oc11ac50.20 GB (14) (done)
13oc11aa50.20 GB (7) (done)
24oc11ac50.07 GB (5) (done)
26oc11ae50.20 GB(done)
total available channels on disk:9828
channels in progress:54
channels done:315
channels ended in error:48
total channels to do:5811
: channels in progress
: 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.

 

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.
Hosts
  • anakin: Intel Server (2 x 2.8GHz Xeon, 4 GB RAM)
  • bane: Intel Server (2 x quad-core 2.66GHz Xeon, 4 GB RAM)
  • bruno: Intel Server (2 x 2.66GHz Xeon, 8 GB RAM)
  • carolyn: Intel Server (2 x quad-core 2.4GHz Xeon, 96 GB RAM)
  • jocelyn: Sun V40z (4 x 2.2GHz Opteron, 28 GB RAM)
  • lando: Intel Server (4 x 3.20GHz Xeon, 4 GB RAM)
  • marvin: Intel Server (2 x 2.66GHz Xeon, 16 GB RAM)
  • maul: Intel Server (4 x 2.66GHz Xeon, 8 GB RAM)
  • oscar: Intel Server (2 x quad-core 2.4GHz Xeon, 96 GB RAM)
  • synergy: Intel Server (2 x hexa-core 2.53GHz Xeon, 96 GB RAM)
  • thinman: AMD Server (2 x 2.4GHz Opteron, 16 GB RAM)
  • thumper: Sun Fire X4500 (2 x dual-core 2.6GHz Opteron, 16 GB RAM)
  • vader: Intel Server (4 x dual-core 3GHz Xeon, 16 GB RAM)
Database/file status states
  • 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).
 

Copyright © 2012 University of California