Running SETI Under WINE

WINE (Wine Is Not an Emulator) is an Open Source implementation of the Windows API on top of X and Linux. It's like a Windows compatibility layer that allows you to run Windows programs on Linux.

You can download WINE packages for most common Linux distributions from here. WINE can be quite difficult to properly configure. I have found a utility called the Wine Setup Toolkit (winesetuptk) to make the process a lot easier. Either a google search or a search of your favourite RPM repository on winesetuptk should hopefully find an RPM version for your Linux distribution.

The advantage of Running Seti under WINE on Linux is speed. The native Linux Seti client is about 20% slower than the Windows Seti client on the same hardware. This is due to differences in the compilers used to compile the respective clients. The Visual C++ compiler used to compile the Windows version is able to create more highly optimised code than the gcc compiler used to compile the Linux version.

Once you have wine properly installed and configured, running Seti under wine is simply a matter of copying your Windows Seti directory to your Linux machine and executing as follows:

cd seti
wine seti.exe

Passing Parameters to Seti

Command line parameters may still be passed to the Seti client as under Windows, although the syntax is slightly different. I have found two forms of the syntax to work, depending on the version of WINE and/or Linux distribution. Examples of the two different syntax are shown below for passing the -proxy switch when connecting to a SetiQueue server:

wine seti.exe -proxy 192.168.0.1:5517

or

wine -- seti.exe -proxy 192.168.0.1:5517

We can also set the Linux nice switch to control the priority at which Seti will run. Positive numbers are high priority and negative numbers are low priority. I usually run the process at a priority of -18 to ensure that the computer remains responsive to other tasks.

nice -18 wine -- seti.exe -proxy 192.168.0.1:5517

However, there is a bug that can occasionally cause the Windows Seti client to hang when attempting to return results to the server. This only appears to happen when running the Windows Seti client under WINE. The solution is to process the work unit using the Windows client, but return the result using the Linux version. We can achieve this by the following script. Simply save the script below as a plain text document, make it executable, place it in your path if necessary and run it.

#!/bin/bash
cd /path/to/my/seti/dir

while [ -f user_info.sah ]; do

   if [ -f result.sah ]; then
      ./setiathome -stop_after_xfer
   else
      wine -- seti.exe -stop_after_process
   fi

done

Note

Remember to edit line 2 to reflect the location of your Seti directory and add any additional parameters as required. The script requires both the Linux client (setiathome) and Windows client (seti.exe) to be present in the working Seti directory. Edit the script or your client filenames as appropriate.

However, I noticed a slight problem (well, more of an annoyance) with this script when using it in conjunction with a SetiQueue server. The above script uses the Linux client to upload results and download new units. However, because the WU was processed with the Windows client (under wine), SetiQueue always thinks it's come from a windows machine (queue). Therefore, on the SetiQueue server you end up with 2 client/queues, one Linux that only ever gives out units and never receives any results, and a separate Windows client/queue that only ever receives results that it doesn't know it ever sent out. The net result is that units sit around in the Linux queue once sent out never knowing they're being returned.

The solution is to only use the Linux client to return results, not to get new work units from the queue. That way the queue server thinks it's an ordinary Windows queue. The way to do this is with a combination of the -stop_after_process switch and stop_after_send.txt file. A revised script that works when connecting to a SetiQueue server is shown below:

#!/bin/bash

# Edit the path to your Seti directory
cd /path/to/my/seti/dir

# Check the stop_after_send.txt file is not present by first creating it, then deleting it.
# If you try to delete it and it's not present you get an error.

touch stop_after_send.txt
rm stop_after_send.txt

while [ -f user_info.sah ]; do

   if [ -f result.sah ]; then
      touch stop_after_send.txt
      ./setiathome -proxy 192.168.0.1:5517
      rm stop_after_send.txt
   else
      nice -18 wine seti.exe -proxy 192.168.0.1:5517 -stop_after_process
   fi

done

A thread discussing these scripts may be found here. Please feel free to use and/or modify for your own use.

Home