This will currently concentrate on running the setathome v3.x client under x86/Linux, however a lot of this will apply to any Unix.
There seems to be a few areas that are causing confusion/panic. Namely
Update: There used to be four clients to choose from for the x86 architecture (see the second client list further below). As of April 8th 2003, there is only one x86 client. i686-pc-linux-gnu.
Well, this simplifies the client choice somewhat ;).
Ok, so here's a list of the clients as of April 8th 2003 (Version 3.03/3.08).
Well, there are two things to determine.
uname -mor the
archcommand. On my machine this produces i486.
For the second, this may be a bit more tricky.
There are several Linux setiathome clients to choose from, as of the 11th January 2002. With the latest version of the client being, 3.03.
However despite all of the above, the choice is really quite simple. For the (g)libc question you are either glibc 2.1 based or not. As for the cpu type that should be fairly simple to determine.
For non x86 hardware the choice is fairly simple. For x86 you have to be a little more careful. Going back to your output from uname -m. if you get i386, i486 or i586 then you need one of the i386-* clients. If you get i686 then you need one of the i686-* clients. Now for the second part of the puzzle, there are again two choices, if you have glibc-2.1 then choose the gnulibc2.1 client otherwise choose the gnulibc1-static client.
Consult the following the table to get a better idea of what client to choose. If in doubt choose the i386-pc-linux-gnulibc1-static client as it should work on any x86/Linux system.
| i386-pc-linux-gnulibc1-static | i386, i486, i586 and not glibc 2.1 AMD K5 K6 K6-2 K6-3/Cyrix 5x86/ Pentium, Pentium MMX, |
| i386-pc-linux-gnu-gnulibc2.1 |
i386, i486, i586 and glibc 2.1 |
| i686-pc-linux-gnulibc1-static |
i686 and not glibc 2.1 Cyrix/IBM/National Semiconductor 6x86MX, MII/Intel Pentium II & III, Pentium Pro, Xeon, Celeron, AMD Athlon/Duron |
| i686-pc-linux-gnu-gnulibc2.1 |
i686 and glibc 2.1 |
NOTE: If you are running recent 2.4 and recent nfs-utils, then probably you should have no problem. Linux's NFS implementation has improved greatly over recent months. See nfs.sourceforge.net for latest information, patches and nfs-utils.
Well this can cause some problems. Mostly the client will refuse to run saying that there is already an instance of it running, whether you remove the lock file or not.
One of the problems here is partly due to Linux's NFS implementation. It is one of the few black spots in Linux, though things seem to be progressing in the right direction now.
Basically the problem is that the setiathome client is trying to get a file lock on a file called lock.sah, this is failing to happen over NFS. Not everybody will see this problem, but it had me stumped for a while. If I remember correctly it won't effect people running a standard Linux kernel 2.0.xx. It will probably effect people running Linux kernel 2.2.xx with nfsv2. It will effect people running Linux kernel 2.2.xx with the nfsv3 patches.
There are two solutions to this problem.
Firstly and the most simple is to just create a file in say /tmp called
lock.sah
This could be accomplished using the following command
touch /tmp/lock.sah
Then in the setiathome directory create a symbolic link to /tmp/lock.sah using the following command.
ln -s /tmp/lock.sah lock.sah
This avoids any locking over NFS.
The second solution requires that you run lockd and statd on the client and server systems. The server should already be running these. If you are not the administrator of the system you are running your setiathome client on, then you should just use the first solution, otherwise read on...
If I remember correctly lockd should be running already as a kernel thread, for statd you will need to get the knfsd-utils package. Try nfs.sourceforge.net for pointers. Once you have the package and have statd built if it's not already and have it installed, start it up. There should be a test program that comes with the utils, that will test if locks over nfs work. If successful, try setiathome now, it should run OK (NOTE: the above should be done as root). If not, it is quite likely that for some reason the nfs server is not running lockd and statd, then go with the first solution.
The setiathome client is not multithreaded and can not make use of more than one processor at a time. Also the client uses about 13 MB of memory and depending on what priority it is set to, will just use up spare cpu cycles, so running multiple clients on a UP system won't really gain you anything. So if you have an UP (single processor) system, then run just one instance of setiathome.
On a SMP (Symmetrical MultiProcessor) system, the general rule it to run one client per CPU, so e.g if you have 2 CPUs run 2 instances of the client, if you have 4 CPUs run 4 instances of the client. Running each client with the same priority e.g 19, should get them placed to run on each cpu. Also it is important to run each instance of the client in a separate directory e.g seti0/ seti1/ seti2/ seti3/. Needless to say each client is working on its own work unit.
Patching or cracking SETI@home.
This problem started out with a German called Olli, who thought he could do better than the SETI@home team. He decompiled the setiathome client, and then released a new version of the client containing replacement code that he'd put in, he was trying to speed the client up. This might initially sound good right?. WRONG.
An often asked question that people ask, is why haven't the SETI@home team released the source code for the client for all to see and improve. Well there is good reason why this won't happen. Integrity of the science of the project. With everybody running the same analysis code, the SETI@home team can know that all the work units have been processed correctly or (heaven forbid) wrongly. Also an important part of the project is the rechecking of work units that have been flagged as interesting. With everybody using the same code, they can easily check a work unit and verify the results, knowing that they are using the same code that was originally used on the work unit.
Additionally the speed increase from the patched client doesn't really gain
you anything overall, there are plenty of bottle necks in the system as a
whole. You may move up the stats table quicker but it won't really help you
find E.T any quicker. This is because there is already an excess of
computing power and if everybody finishes their work units quicker then the
supply of new work units will quickly run out and people will just be sent old
work units (or units that have failed to be returned at the time) and there
will be a huge duplication of effort.
Because of all this computing power available the SETI@home team are
planning to add more analysis code to check for more types of signals, this
will also have the effect of increasing the time it takes to process a work
unit, which is desirable to the SETI@home team.
So in short DON'T USE A PATCHED CLIENT, it won't gain you anything and will only make the lives of the SETI@home team that much harder. There is a web site devoted to the issues of patch-free-processing.
To get more info on the above, check out the SETI@home FAQ. It is also posted regularly to the alt.sci.seti and sci.astro.seti newsgroups.
Installing and running the client.
This seems to pop up regulary.tar xvf setiathome-2.4.i386-pc-linux-gnu-gnulibc2.1.tarthen to run the client, cd into the newly created directory and issue
./setiathome -nice 19 > /dev/null &the ./ is important, this tells your shell you are executing a command in the current directory. The
-nice 19tells the OS to run the program at the lowest proirity, basically just sucking up idle cpu cycles. The
> /dev/nulltells the shell to discard the programs stdout. And the
&tells the shell to run the program in the background.