In the course of installing or reinstalling BOINC, and attaching or reattaching to the project, you may end up with multiple identities (hostids) for the same host computer. This is annoying and can also cause some work to be lost if work which was sent to the 'earlier' computer got wiped out in the installation or detach/attach process.
A simple way to fix this is to go to your Dashboard -> Computers. Select the newly created host by clicking on its hostid in the left-most column. Go to the bottom of the page, click 'merge' and follow the instructions to select which other computer(s) to merge this identity with.
Go to this page to request a new password. You'll receive an email with one-time login link that allows you to change your password.
There are a number of possible reasons. In most cases, the Einstein@Home scheduler sends a detailed text explanation to your machine. But the BOINC client does not always display these messages correctly or clearly. So if in doubt, look in the sched_reply.xml file, located in the directory where BOINC is installed, and search for lines that have the word 'message' in them. Note: please take care not to corrupt this file!
In the BOINC client, in the 'messages' window, these messages often appear to the right of 'no work' but are hidden because the corresponding column of text is too narrow. Widen the column as much as possible to see the full message. This works sometimes, but not always!
Sometimes, your machine is not sent work because the amount of memory required (currently 70 MB) or disk space required (currently 100MB) is too large. If the problem is memory requirements, please check back in a week or so. We are working to reduce the memory requirements of our application. (Of course, you can always add more memory to your machine, but that's a bit much for us to ask!) If the problem is disk space, please review the way that you have set your disk space preferences under Your Account. For example, if your machine has a 4 GB disk, but you have set the preferences to 'Leave at least 5 GB free space', your machine will never get sent any work because the scheduler can't satisfy the constraint you have imposed.
In other cases, your machine will not be sent work because the scheduler has estimated that the work would not be completed in time (before the reporting deadline). This estimate takes into account a number of factors: (1) the amount of work currently queued on your machine, (2) the resource share fraction devoted to Einstein@Home (as opposed to other BOINC projects) (3) the fraction of time that your machine is turned on, (4) the fraction of THAT time during which your machine is available for running BOINC. In this case, you can leave your machine on more of the time (the scheduler will notice this over a period of a few days and start sending larger amounts of work) or you can change your preferences for when BOINC runs on your machine (for example, set it so that BOINC runs all the time, instead of only when your machine is idle.)
In other cases, your machine will not be sent more work because it has already been issued with its daily quota of workunits (currently set to 8 workunits per CPU). In most cases for which a machine is running up against daily quota limits, there is a problem with the BOINC installation or Einstein@Home execution on your machine, and it is 'erroring out' the workunits and returning them as unsuccessfully completed. You can see if this is the case by going to 'Your Account' on the Einstein@Home web page and reviewing the results for that machine. The stderr error messages may reveal the problem. If you can't fix it yourself, please post a message on the message boards in the Problems and Bug Reports section.
This is described here.
Your general settings are set to "Do work while computer is in use".
Go to your Dashboard and edit your general preferences so that "Do work while computer is in use?" is set to No. You can then do and update project to make your computer use your new settings.
In order to get credit, the successful results from your computer have to be validated. This means that they are automatically compared to the results from at least two other computers, doing the same work. It may take some time (often a week to ten days) before other machines have been sent (and have completed) the work. If your machine is generating successful results, just be patient, and keep running Einstein@Home. Eventually the credits will start to accumulate!
If you want to see the status of your jobs, go to your Dashboard and follow the links labeled 'Pending Credit' and 'Results'. Note that once you have returned a successful result, you WILL eventually get credit for it, provided that the result is determined to be valid. Once a successful result from your machine is registered on this page, it's like money in the bank. You might have to wait a while to get credit, but once enough other successful results have been returned, and your result is found to be valid, you will get credit for it. The deadlines that you see on this page are 'individual', meaning that each workunit assigned to a different machine or user has its own deadline.
Note that from time to time (less than 1% of the time) results that are in fact correct will get marked as invalid, and you will not get credit. This is because our validator, the program that compares results, is not perfect. So if you have an occasional invalid result, don't worry.
In order to help the project to complete its work and others (and yourself) to get credit quickly, try to make sure that your computer doesn't download more work than it can complete by the deadline. Do this by setting a small value (for example, 0.5 day) in your preferences, for the value of 'Connect to network about every X days'. This will ensure that your computer doesn't download more days of work than it can complete. This helps, because work which is not completed by the deadline is considered 'overdue' by the Einstein@Home scheduler, and it will issue a duplicate workunit to another machine, wasting resources.
The credits are pending because two other machines have not yet completed the same work, and so it can't be validated yet. Don't worry: the BOINC scheduler will send that work to other machines (and keep trying if they don't do the work) until the same work has been done by several other machines. This can typically take a week or ten days, or sometimes even a bit longer. Just be patient.
The fact that you have pending credit proves that you have completed a result within the deadline. Don't worry about how long it takes for the required extra two successful results to appear before validation can take place. Provided that your result is valid, you'll get credit for it. Pending credits are like money in a bank savings account. It may take some time before you can withdraw them, but they will eventually pay off.
If you have a fast machine, the odds are higher than you will be the first person to return results for a given workunit. The odds are also good that the other machines that get assigned the same workunit will return the results more slowly than your machine. So, statistically speaking, if you have a fast machine, you'll have to wait longer after crunching a workunit than someone with a slow machine, before your results are validated and you get credit.
Each machine that does work will claim a slightly different amount of credit. For fairness and uniformity, we have adopted the BOINC/SETI standard way to determine how much credit to award. Since each unit of work is done by more than one machine, we use the credit claims of all these machines to determine how much credit to award. Every valid result for a given unit of work is then awarded exactly the same amount of credit.
To determine this, if three or more results are valid, the high and low credit claims are dropped, and the remaining credit claims are averaged. If less than two results are valid, the LOW credit claimed is awarded.
See see previous question!
You won't be shown as a member until you have accumulated some credits while registered as a member of that team. So please be patient!
To see the graphics, your has to support OpenGL graphics and X11. You should then be able to highlight a running workunit in the WORK tab of the BOINC Manager and use the 'Show Graphics' option to display the screensaver.
Please see the following. It applies to us because Einstein@Home is a multi-threaded application.
Question: Why is %CPU underreported for multi-threaded (Java, etc.) apps?
Answer: You need to upgrade to the 2.6.10 kernel at least. Older kernels do not provide a reasonable way to get this information.
BOINC and thus Einstein@Home requires MacOS 10.3 (Darwin 7.3) or later.
This information is kept in the file client_state.xml in the fraction_done tag.There are third party tools that read it. If you want to have a quick look, open a Terminal, cd to the boinc directory and grep for fraction done:
cd BOINC; grep fraction_done client_state.xml
You may put this in a loop for watching it continously:
cd BOINC ; sh -c 'while grep fraction_done client_state.xml ; do sleep 10 ; done
The value shown is the fraction of the work done, so a value of 0.34 means 34% done.
The "exited with zero status but no 'finished' file" is a known bug in BOINC that we still couldn't track down. It tends to show up on Multi-CPU (or HT) systems, and if you look into stderr.txt in the slots directory you will probably find a message saying "no heartbeat from core client". However the Result is properly restarted by the client and will eventually finish, this bug hasn't an effect on the outcome. As long as everything else is working well, you can safely ignore this error message.
When the BOINC client is first run on a machine, it does some testing to determine how fast that machine does floating point and integer mathematical operations. Some versions of the BOINC client do not make this determination very accurately, either over- or under-reporting the performance of the machine. In particular, on Windows machines, the MS compilers optimized away some of the benchmark tests, making the machines appear faster than they were. The opposite effect also arises on Macs and some 64-bit Linux machines, where the BOINC client would show better performance if it were compiled with additional optimization switches.
The Einstein@Home workunits require a large data file (slightly more than 12 MB in size). With a 57.6kb modem, this file will take close to an hour to download. Once you have downloaded it, the Einstein@Home scheduler should send you a number of workunits for that file, so you won't need to download another file for some time. However be warned that sometimes the OUTPUT files from Einstein@Home can be quite large, and so it may take an hour or more to upload the results back to the Einstein@Home server.
The bottom line is that if you need to pay an hourly rate for dial up modem service, Einstein@Home is probably not a good thing to run on your computer. Users with broadband internet connections such as DSL (Digital Subscriber Line) and cable modems shouldn't find that these uploads/downloads take more than a minute or so.
Einstein@Home makes heavy use of OpenGL. The part of this work the graphics card can't do on its own hardware has to be done in software by the CPU, preventing it from crunching. If you have a slow or "dumb" (not OpenGL-accelerated) graphics card, you might better not show the graphics if you want to get your results finished quickly.
Here are a couple of ways to tell if Einstein@Home is being slowed down by your graphics hardware.
Windows users: soon after an Einstein@Home workunit has started, bring up the 'task manager' by doing CONTROL-ALT-DELETE. Find the running einstein process and compare how much CPU time is shown with the time reported by the BOINC client. The BOINC client only reports the CPU time that was used by the 'science' part of the code, whereas the 'task manager' shows the CPU time used by both the science code and the screensaver code. If you watch there for thirty seconds, and the BOINC client reports that the science code has done only an additional five seconds of computation, whereas the task manager reports that the einstein application has used an additional thirty seconds of CPU time, this means that the graphics is consuming most of the CPU time. In this case, you should probably set your screensaver preferences to blank the screensaver after a few minutes. Alternatively, go to the web site of your computer or graphics card manufacturer, and download the latest graphics drivers. If you can switch your graphics to a mode that supports 'accelerated 3D OpenGL' then the screensaver should become very efficient.
Linux users: It's important to make sure that your graphics hardware is using 3D OpenGL hardware acceleration. A good test is to run the 'glxinfo' program. If it reports direct rendering: No then you are NOT using graphics acceleration, and the graphics will be slow and time-consuming. If it reports direct rendering: Yes, then all is well. In many cases, where direct rendering is *not* enabled, you can turn it on. See http://dri.freedesktop.org/wiki/ for more information and a useful troubleshooting section. Running glxgears is a simple way to test changes to your XF86Config file.
Mac users: all recent versions of Mac OSX include wonderful hardware acceleration. You don't need to do anything!
Most modern computer screens are immune to burn-in, but we are still addressing this issue for those who are concerned. At some point in the future you will be able to select an item in your project-specific preferences to ask that static elements of the screensaver not be shown.
We have a deadline of one week between the time that your computer downloads some work, and the time that the results must be reported back to the server. In general, the Einstein@Home scheduler will try hard to NOT give your machine more work than it can do by the deadline. Normally these workunits take between 5 and 24 hours to do, so as long as your machine is available for Einstein@Home more than 15% of the time, it should be able to complete work on schedule.
We have received requests to increase these deadlines and may do so in the future. For the moment these are short for two reasons. First, if we increase the deadlines, this means that the work and result databases get bigger, because there is more work in progress. Currently, the database is the most overloaded part of the Einstein@Home server, and the part that does not scale well. So we are trying to keep it 'lean and mean'. Second, increasing the deadlines means that it will take longer for users to get credit. Since credits are the easiest way to keep track of whether or not your computer is working well and making a positive contribution to our research work, we would like to try and ensure that you get credits awarded in a timely way.
If you are having trouble completing work by the deadline, the simplest and best thing to do is to decrease the size of your 'work cache'. Go to your Dashboard and edit your general preferences so that 'Connect to network about every N days' is set to 0.1 days. This way, your computer won't download more work than it can do in a single day. Note that if you run multiple projects, you may need to set this value on the preferences page of your other project(s) too.
Answer not written yet.
Answer not written yet.
This question is under discussion between the LIGO and GEO labs, and the LIGO Scientific Collaboration. It has not yet been answered. Here are a few facts that are relevant. (1) Einstein@Home participants are carrying out one step (the most computationally-intensive one) in a pulsar search. However the results are fed back into a later stage of search which looks for consistency between different independent results. So no single user 'makes the discovery'. (2) Since (for the purpose of validation) the work is done by several machines independently, belonging to different users, any credit should be shared between the different users who got that result.
We expect to update this answer in the future.
This problem occurs when your machine contacts the Einstein@Home scheduler to request work, and the Einstein@Home scheduler sends work to your machine, but the work never arrives. This can happen if the networking connection fails during the data transfer. It might also happen if your machine never gets its original assigned hostid and later gets given a different one. It might also happen because of (known and perhaps unknown) bugs in the BOINC core client.
We hope that this problem is largely fixed. If your machine is behind a proxy server or part of a Windows network that uses proxy-like translation features, then bugs in the BOINC 4.19 client may cause this problem. If you see this happending repeatedly on your machine(s) please file a report in the message boards, and perhaps try one of the later BOINC versions.
NOTE: If you are using a proxy server make sure that the TIMEOUT interval for the proxy server is set to at least 100*N seconds where N is the number of CPUs on your machine. Otherwise your proxy server may drop the connection to the Einstein@Home server before the scheduler reply is sent from the Einstein@Home server to your machine. So for a single CPU machine be sure to set the timeout of the proxy server to at least 100 seconds, for a two CPU machine, be sure it is at least 200 seconds, and so on. This also applies if your machine is networked by using another machine as a gateway to the internet.
Provided that your machine is successfully completing work, uploading the results, and downloading work, the occasional lost Workunit is nothing to worry about. When it times out after the deadline, the work will simply be sent to another host machine.
This was an erroneous error message and can be ignored.
There are some host machines which 'error out' all the work that is sent to them. Often these machines are misconfigured or have some other Operating System or BOINC installation problem which needs to be fixed. To help reduce the impact of these machines on the project, we use a 'Daily Result Quota' to prevent these host machines from trashing hundreds or thousands of workunits per day.
The 'Daily Result Quota' is normally 8 workunits (per CPU, with a 4 CPU maximmum). A host can request, and will receive, up to this many workunits per day and per CPU. Each time that a host returns a failed result, or 'times out' on a result (fails to return a result by the deadline) its Daily Result Quota is reduced by one. Each time that a host returns a successful result, its Daily Result Quota is DOUBLED. Note: the Daily Result Quota is NEVER allowed to be less than one, and NEVER allowed to be larger than 8 (per CPU).
Provided that a host machine returns at least some successful results, it's Daily Result Quota should remain near 8. Host machines that have a Daily Result Quota of 1 should be examined: there is probably something wrong with them, or with how BOINC in installed or running on them.
Probably not. We use stderr to log some useful information that helps us to track the execution of the search code. The following messages are normal and not signs of trouble:
Resuming computation at X/Y/Z
detected finished Fstat file - skipping Fstat run 1
detected finished Fstat file - skipping Fstat run 2
Fstats.Ha: bytecount X checksum Y
Fstats.Hb: bytecount X checksum Y
The following messages indicate that your Linux machine does not have the necessary libraries to display Einstein@Home graphics. Provided that you don't want graphics, they can be ignored.
dlopen() failed: libGL.so.1: cannot open shared object file: No such file or directory
graphics_lib_handle NULL: running without graphics
Please download memory.c. Follow the instructions at the top of the file to compile and run this small program. Then report the results in the forum, along with the host ID of the host machine.
The Einstein@Home workunits have three stages. In the first two stages, two different sections (different time ranges and/or detectors) of Gravitational Wave Detector data are searched for the same set of candidate physical sources. In the third stage, the results of these first two searches are compared to identify candidate sources which appeared in both sections of the data.
The first two stages are entirely deterministic: we can accurately say how much work has been done by your computer and how much remains. The third 'coincidence' stage is not deterministic. Normally it should only take a few seconds although in some cases, for some sets of candidates found in the first two stages, it might take several minutes or even tens of minutes.
The Einstein@Home application is designed to report progress from 0% to 49.5% complete in the first stage, and from 49.5% to 99% complete in the second stage. The third stage reports progress in an unpredictable way, from 99% to 100%. This third and final stage should normally complete much faster than 1% of the time used by the first two stages. However in some cases it may take a number of minutes.
This happens if work being sent to your machine is lost enroute. What may be happening is that the workunits are being lost as described here and as a result your daily result quota is being reached. These lost workunits can also result in a lowering of your daily result quota as described here.