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!

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.

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!