(last update sum table of performance 5. Dec 2001)

For those of you, who want to improve or extend (or both) your SETI@home efforts, I share in the following my experiences with the LINUX (text-only and graphical X support process) and the MS Windows Screensaver clients, details are true for the Version 2 resp. 3.03 of the client now generally used. If you think, that I'm insane after reading this account, than please keep in mind, that I'm a scientist, optimization fan and computer expert, and also I think that many people will share at least one of these two main motivations of doing such elaborate things: a serious intention of participation in an unusual, but interesting scientific enterprise and a more sportive like wish of doing well in competition... For general features of the client usage look on this page , if you are not yet familiar with these. I have to regret, that I can't share any experiences with you regarding the nice MacIntosh, because I have no such computer available anyway (hi Mac users --- you are invited to send me your own experiences and tips!). But I suppose, in some respects it might be more similar in usage to the MS Windows then to the UNIX client(?). But of course the new, BSD UNIX based MacOS X (server) system is again like any other UNIX SETI@home client, despite there is now a graphical screensaver version available too.

One concluding general remark: if a computer is not your own, ALWAYS ask the responsible(s), if you may use it for SETI@home at all and when, than also, if you are allowed to connect from it to the SETI data server in Berkeley! If you are allowed to use the computer, but not to connect because of costs or you are unable to connect for some technical reason, read the second section below. And finally: do the necessary work only in breaks respective before beginning officially to work or after finishing the officially (time counted) work as I always do!

You may jump straight to these other two sections:

 disk copying to not connected computers and similar

 get the absolute maximum of your computer resources  [additions on 5. Mar 2000]

Run a single Client as fast as possible

As a general remark: any graphical display of the client or client helper process is a waste of time. The only difference between platforms in this respect is, how much of the available CPU time is wasted (or more precisely, taken away from the calculation part of SETI@home and all other tasks on the computer). This may sound a little disappointing to you, but I will present you the facts now.

LINUX/UNIX: the client is virtually the same for all these systems, so I will make only two short remarks about it: first, only for few platforms (SOLARIS especially, that's straight because Berkeleys SETI people use it!) the x-SETI extension was available, so I can only now tell you, how much time you lose by using it: my estimates for my own LINUX computer due to a test is about 14 to 19 percent more CPU time in total is needed for a work unit, much less then with the insane MS Windows, but still considerably for the eager "number crunching competitor". The other chance to improve is: use the default behaviour, which shows only how much of the work unit is already processed, because the former default and now also by the verbose option available behaviour is also wasting (only a bit, of course) CPU time by displaying texts about the many fast Fourier transformations and Gaussian curve fittings. If you are calculating a lot of these units, this will be not unimportant for the sum of them. That the Version 2 is faster than it's predecessor, can in my view be at least partly attributed to the change of this text output behaviour (the performance increase seems to be about 3 to 4 %). These numbers hold true for the shell window usage, but I suspect, that even discarding the texts into /dev/null by a cron job or similar measure will make a difference.

MS Windows (95(/98)) Screensaver version: as I mentioned above, the screensaver or display window usage is a massive waste of CPU time! I observed, that the client runs triple(!) as fast without graphical display of its progress. Of course for doing so, you have to choose the configuration setting "run always" --- and that requires at least 64, better 128 MB RAM in your computer and a reasonable fast machine (I guess, Pentium(II, III) machines with 200 MHz or more should be sufficient for this). Because otherwise the client will slow down nastily all other work on that computer. Because as default the SETI sreensaver is installed, you have to change this to "no screensaver" or use another one, which doesn't waste much CPU time (many of them waste a lot of it!). For example, you may use the text moving screensaver with settings: no rotation, minimum speed, minimum size and so on, to save time which is used by the screensaver.

Another hint: close always any application besides SETI@home, which you are not using for more than several minutes, because by the lack of a reasonable task scheduling even "sleeping" (hard to tell, if this is an appropriate notion for the behaviour of this messy OS!) tasks take away a lot of CPU time! In this way I got a negative "record" of 55 hours for one work unit on a 400 MHz Pentium II (!), compared to about 30 hours without permanantly active rivaling tasks and about 10 hours without graphical display too! Also these measures are very inaccurate, because SETI@home is only measuring the time, in which it is active, and NOT the actual used CPU time --- also due to the lack of reasonable support by the OS. Microsoft sucks indeed (keep in mind, that the Amiga could do such things accurately and correctly already more than 10 years ago!).


Use every Computer You can (and are allowed to!)

At principle you need only one computer, which can and may connect to Berkeleys SETI data server, for using an arbitrary number of others without connection too --- if you are willing, to invest some more manual work. There are only three "secrets" in it: a floppy disk, copying of files and "cleaning" of working directories.

Only three of the *.sah (formerly (<V2) *.txt) files are important for doing so (now I omit the extensions): work_unit, result and user_info. That means the following: if you have a computer without connection to the data server, you may install the client as usual, eventually choose your settings and then exit it (or don't start it in the first place anyway). Than you copy the user_info file (by a floppy disk, if you lack any form of network between them) from any computer, which gets the connection, into the working directory of SETI@home (in MS Windows mostly in \programs\SETI@home, but you may change this to another one during installation) of the computer without connection --- regardless, if or how actual the user_info is (preferably one with correct basic informations like the email address!). Now it is ready for work, the only thing which it still needs, is a work_unit. With this you proceed in a quite identical manner, than you can (re-)start the client! When the client is finished, than you get your usual result file, the work_unit is also automatically deleted. All you have to do now (don't forget the client to forbid the connection trial, if you could connect but are not allowed to again!) is, to move (i.e. copy (on floppy disk or in the local network), and than delete it) from the working directory. Now you put this result file into a working directory of a not running client directory of the (a) connecting computer, but don't forget to delete ALL *.sah (formerly *.txt) files from this directory but the result and the user_info (maybe you keep also the version file, this doesn't matter) files. Now you can start this client and it sends the result to the Berkeley server as usual and downloads the next work_unit for the other, not connecting computer, so you have to copy again the work_unit (and maybe the user_info, but it's not necessary!) to the other computer and so on... This works also with different platforms! That means, the OSs of both (or all) participating computers may be different, you are able to mix UNIX, Mac and any insane MS Windows platforms to your like... This is due to the usage of simple text files respective identical binary data on these systems by Berkeleys creators of the SETI@home software. Remark: for any UNIX systems you can get a bunch of more or less simple scripts for copying and more on another page...

One final question may now arise: how the heck, you may ask, can I afford this on a connecting MS Windows machine? Again this is a drawback of these systems; because on any UNIX system you may create simply as many SETI@home directories as you wish and are able to run as many of them as you want and as your computer can afford in terms of memory. Therefore on UNIX you may in the simplest case use one (or more, see below!) directory for the computer itself and one for each other computer, which is "fed" by copying files through this connecting UNIX machine, this/these other(s) of course only for data transfer. On MS Windows, as usual, this gets a little more complicated (only the NT/2000 text client gives a little (!) more UNIX-like comfort like usage of several directories and running client instances):

Install the client twice, but you have to rename an already installed client directory (ignore the annoying MS complain about this, now and forever!) to enable a second instance to be installed, you may give it the same name as the other before you renamed it. Now you have always to swap (rename!) the two directories at any time, when you need the other one (the own, or the transfer directory): the one for the own calculations and the one for the file transfer for the "companion" computer. One has to be named as the second installed directory, the other may be named similar, for example insert simply a "r" or "s" at the beginnig of the (unused) directory name before renaming the other into the installation name one...


Maximize Your general, total Throughput of Work Units!

You may ask, what now still remains? If you haven't yet be astonished, you will be probably baffled by my following explanations. But step by step...

Despite some own environmental, especially energy consumption concerns I have to pronounce the simple fact, that running the computer is not avoidable, if you want to do anything on it (besides hardware changes, of course), regardless if it's SETI@home or anything else. Because this needs a lot of CPU time and if you want to get high in terms of work units processed per time, you have simply to assure, that the computer is running as much as possible, and during it is running, that SETI@home is running at best always, when the computer is on.

You have to decide yourself, how many time you want or may run every participating computer for SETI@home reasons. I can't give any advice in this point besides turning off your monitor always, when you not need it for hours or more --- but I can do so in the second: running SETI@home without interruptions. There are several possibilities, which I will present as several items now for different "SETI@home environments":

  • the easiest case: you have "your" UNIX computers running as system responsible for example in an university with a permanantly present high bandwidth connection. Then you may choose one of two options (of course run these SETI@home clients always as "nice" processes (option!), to avoid a slowdown of any important processes, daemons and user tasks!): starting the processes as described in the readme with the init level you usually use (generally 2 or 3, I suppose). Alternatively you may start 'em by cron, preferably not by roots cron for security reasons (I don't know, if there are any gaps, which could be exploited by the insane hackers, but be better safe then sorry, especially in such a position!). Easy life for you indeed, all what you have to do after installing the client on every computer alongside with the init scripts and/or cron entries is, to look sometimes on a user_info file, to control your probably fast progress --- or look at your statistics on the SETI server itself!

  • especially at home you may be not able or simply not willing, to let connect the client without your manual okay to do so. Than you have a little more difficult life with SETI@home, if you want to maintain a high throughput of processed work units. It can be necessary for example, to get some more actual work units, then you need at the moment, to keep the system running permanantly with SETI@home. Because it depends heavily on the OS, what to do now, read one or both of the following points!

  • manually connecting a UNIX client: there is a built-in option to exit after processing a work unit (-stop_after_process). But if you are not always ready (I don't want this to be interpreted like "if you are no USMC member") to get into the process, for example in the "strange" case, you are meanwhile at work, you may lose plenty of time by getting it stopped and waiting for you for the file transfer thing and restart of processing afterwards. There is a simple solution: create TWO (or especially on very fast machines more) directories and ensure, that at least one of them is always running, despite one or more are finishing during your absence (as some sort of "insurance" you may even run always or mostly two at a single CPU, because sometimes --- less in 1% of all cases according my experience --- a client process exits unexpectedly early due to a RFI problem, which can't be handled through the client, so it gives up early)! Don't worry about running several of them at certain times, this causes ABSOLUTELY no loss of performance in total (as you not exceed the memory, your computer offers you for these several clients (up to 16 MB required for each process) without paging/swap space usage)! You may find the corresponding control and other shell scripts for offline and for permanent online environments useful. Finally this script is a little gimmick: I called it after the well-known fortune "utility" for the simple reason, to use it with the xlock mode marquee instead of fortune (means you may to have to change your search path for it, when the "real" fortune is present!): with a delay parameter of 300,000 it works good, changes often enough but not every time on all but very fast machines and is opposed to any screensaver solution taking nearly no CPU time away from the real SETI@home client processes. Adapt to your directory (-ies) and watch the text displaying the progress/status of the crunch!

  • a similar solution is possible, if you are using one of the by far too widespread MS Windows systems, but a little more complicated again: see above first for the renaming trick, than proceed as follows: during you are present, you may run one of the two directories at any stage you want. But immediately before you leave for longer time (over night at work or over day at home), you rename = swap this directory with another one, which contains a "fresh" work unit (not started to be processed yet), to gain maximum time of running the client during your absence. This is important especially for fast machines, of course, and may need a little thinking to get it "right", this means optimized, to avoid at best long times of not using the computer...

  • Attention: the lucky people, who are allowed to run SETI@home on real UNIX powerhorses like Silicon Graphics or SUN SPARCserver should be aware, that they have to run at least one client per computer CPU! Otherwise you get not the maximum throughput from these fine machines... But keep in mind, that every client instance needs up to 16 MB main memory, and this may limit your acceptable number of parallel running clients to a number below of your CPUs --- anyway, for example for sole performance you could run on a SPARCserver with 8 CPUs, from which you know, where only one CPU runs at 50% usage and another with 5% at the average (often met, I'm sure!), you could run 6 clients without any concern, as long no paging due to the clients occurs! Some scripts for general and for control may help you.

  • during a longer absence you are simply left by the nasty MS platforms of course. But this doesn't hold true for UNIX, as you could already read above (first point, for example). There are two possible solutions even for manually connecting people: of course you have always to download enough work units for your absence, you can easily calculate how many, by using your average time for one unit and calculate therefore the number by dividing your (expected!) absence time through the average processing time. Than you have to arrive at a decision: if they are not too numerous, you may create enough directories and start simply all clients in these before you leave. But this can be a problem, if they are really many regarding your computers memory. The better solution, especially for longer absence and fast machines, is to use cron and scripts for accomplishing this task. You may write it so, that always 1 or 2 of the processes in these directories run, and another one is started, if the number of active ones falls below two... I have written now such a script and share it on my explanation page with the interested (mostly LINUX users at home with a modem, I guess!) still in March 2000.

Now I will close this page with two final points: first my own schedule to get the most out of my resources for SETI@home, and then finally some more general considerations. 

(German flag evtl. interesssiert dies auch manche Mitglieder des Vereins Schwäbische Sternwarte e.V., die sich über meine Anzahl gerechneter work units gewundert haben?)

This first part is now only of historical interest. My "SETI@home environment" consists of now four computers, which are useful for me: a 333 MHz Pentium II computer (BIOS SDRAM access time now lowered from 12 to 10 ns), running (SuSE) LINUX with Kernel 2.2.16(2) at home, equipped with one ISDN card; and a 400 MHz Pentium II computer at "my" company, running the "badly behaving" (to say the least) MS Windows 95, part of the LAN of the company and able to connect to the internet by demand for business usage, but not allowed to initiate for such private purposes any internet connections. Therefore the third important part of "my system" are floppy disks... Because I have already explained to you many of the tricks I use, I will give the description in a few short words: a total of 15 (!) directories (even more during an absence from me...) is used by me now for doing the work on my LINUX computer, and a total of 9(+6)+3(+1)+4(+2) directories for the computers in the company. Each two or more of these LINUX directories are for: the own need for processing under LINUX (3 for convenience), and for the file transfer to the office' computers directories. The rest should be now clear, if you have read so far all above. Good luck in creating your own optimized "SETI@home environment"! By the way, after all optimization efforts done, which I have described, I need now about 11 to 11.5 hours CPU time for a work unit on my LINUX computer and needed about 10.5 hours CPU time on the 20% higher clock speed using business computer --- this shows still a lack of keeping up with LINUX, because with this OS it would even need only about 9 hours on that machine to finish one work unit. But for now, I have enough complained about MS. Meanwhile my "office environment" has changed to a Pentium II computer also running LINUX with Kernel 2.2.14 at 266 MHz (as formerly my own did) and also using the cron with the setiControl script for keeping the CPU busy every single second, and an additional, rather old SUN SPARCstation 5 with Solaris 2.6 (only one old, slow CPU), also running cron and the script, so the turnaround times times are about 12.5 to 13 hours (using a little faster memory than my own before the upgrade) respectively 45 to 50 hours (old Sparc 5!). At last the another old UNIX machine, a IBM RS/6000 PowerPC with AIX 4.2 has joined these machines at office, which needs about 35 hours at the average for one unit. Therefore my total (pure UNIX environment now) throughput is now altogether about 33 to 37 --- 35 at average --- work units per week, compared to 7 per week at the beginning of my participation (end of September 1999) with my LINUX computer alone and without any of the mentioned optimizations. This was the status before changing to the 3.0 version of the client. As result of the transition, which couldn't be completed yet because of a missing version for the PPC AIX system, the throughput is now only 30 to 31 units per week --- the old SUN was dismissed, because it's now with the 3.0 client too slow to justify further usage.

Current standing with 3.03 client version: now the numbers are like you can see on the performance table page and therefore the expected throughput has dropped with the three remaining computers used to a sum of about 19 to 20 units per week. Newest update: with a replacement of the old RS/6000 by another SUN machine, and with the PIII 550 MHz LINUX computer in the group of computers as well as a new IBM pSeries 44P170 AIX workstation, one more LINUX PC (450 MHz PII) (only temporarily an HP-UX server was active too), I have now a throughput of 60, what's below it's highest value so far of just above 100 per week.

And finally: of course we usual computer users are never able to compete with any single group at modern, big universities, research facilities or big companies, equipped with modern Silicon Graphics machines or SUN Enterprise servers or similar good number crunchers, which are outperforming even Pentium III PCs with 600 and more MHz by huge numbers (needed times for one work unit are partly below one hour per CPU, and they have many of these CPUs each!). Therefore the top users are all using one of the mentioned computers, gaining lots of processed work units or results in very short times. But on the other hand, these facilities are rare (at most a few 100 or 1000), and so the sheer number of "usual" PCs is delivering more results in the sum, because they outnumber heavily the much faster machines! This is the reason, why the Berkeley staff created also a MS Windows client, despite it is on a single machine so much inferior to the faster UNIX machines, but the high number of computers compensates for this drawback, as mentioned, and so even our efforts to get the most out of our limited resources will pay off, if enough people will follow me and others!
 
 

 top of overview   back to SETI main    back to main

further hints and questions to:  stefan.urbat@apastron.lb.shuttle.de

(URL:  http://www.lb.shuttle.de/apastron/setiTips.htm)