SETIView/2 Cache

SETIView/2 Cache is SETI@Home work unit caching program for OS/2.

Contents

• Description
• Prerequesites
• Installation
• Configuration
• Usage
  
  • SVCache.* Files
  • How It Works
  • Processing The Work Units
  • Returning and Fetching Work Units
  • Sharing Work Units Between Machines
  • SETILog2.CMD
  • Running Under Windows
  • Hints
• Other Stuff
  • Future Enhancements
  • Known Problems
  • Bug Reporting
  • Version History
    • Current Version: 0.1.6
  • Copyright
  • WARNING!
  • Contacts

Description

I have a modem connection to the Internet. And my system was taking about 25 hours to process a work unit. This lead to a lot of slack time as it might complete a work unit in the middle of the night and not get a new one until I connected when I returned from work the next night. Then I saw some Windows based cache programs. One was a set of batch files that I thought could be run under OS/2. But, when I looked at them, I thought they were too complicated. So I decided to write my own. It started simple, but now it's probably as complicated as the ones I rejected!

The features of SVCache are:

• Maintain a set of work units.
• Control the SETI@Home process.
• Return and retrieve new work units as required.
• Allow the number of cached work units to be changed.
• Optionally log process work units in a format compatable with the windows progams SETIWatch and SETILog.
• Allow multiple machines to process work units in the same cache.
• Allow a machine to stop processing a work unit and have another continue the processing.

As to the name: this doesn't have any real relation to my SETIView/2 program. But, I decided to keep the same "brand". I am intending to add a "cache" view to SETIView/2, but that will take a bit of time.

Prerequesites

• OS/2 Warp V4.0. Any FixPak should be OK
• REXX - Tested with:
  • Classic REXX under OS/2
  • Regina under Window 2000
• SETI@Home for OS/2

Installation

The installation and configuration is manual. Here are the steps:

1. Create a directory that will be the parent for the cache directories.
2. Create a subdirectory for each work unit to be cached.
3. Create a file called "SVCACHE.OK" in each subdirectory that will hold a work unit.
4. Copy the "user_info.sah" file into each subdirectory. If you don't do this, the first time that SVCBuf.CMD is run, you will be prompted for the email address to be used to retrieve work units from the SETI@Home server
5. If you have an existing incomplete work unit, copy it into one of the subdirectories.
6. Put the programs in either the PATH or the cache parent directory.
7. Modify the programs according to the configuration section.
8. Make sure you have HOSTNAME set in your CONFIG.SYS. If you are running this on multiple machines using the same cache directories, make sure this is unique for each machine.

Optional: Create program objects for SVCRun.CMD and SVCBuf.CMD. Or arrange for these to be run automatically. SVCBuf.CMD needs to be run when you are connected to the Internet.

Configuration

At the moment configuration is pretty bad. It has to be done by modifying the REXX programs. At the top of each program, there are some variables to be set. These follow the line:

/* Customise here */

The changes are to be put inside the double quotation marks.

In SVCRun.CMD and SVCBuf.CMD the changes needed are:

• seti_program_OS2 = "..\setiathome.exe" - Defines name and place of the SETI@Home program for OS/2. If you use a relative path, it must be relative to each cache directory.
• seti_program_Win = "..\setiathome-3.03.i386-winnt-cmdline.exe" - Defines name and place of the SETI@Home program for Windows. This must be the command line version. If you use a relative path, it must be relative to each cache directory.
• seti_proxy = "" - Define the proxy parameter to be used.
• seti_parameters = "" - Defines any extra parameters to pass to SETI@Home.
• seti_Log_Dir = "..\1" - directory where the SETILog.CSV file will be put.
• setiLog2_params = "/NOBACKUP" - Additional parameters to pass to SETILOG2.CMD. This plus seti_Log_Dir will be passed to SETILOG2.CMD. See SETILog2.CMD for details.

SVCBuf.CMD also has the following:

• start_delay = 60 - Number of seconds to delay the start of processing.

Usage

To run SVCache, change to the cache parent directory and:

• To process the cached work units, run SCVRun.CMD.
• To return the processed work units and get new ones, run SCVBuf.CMD . This must be done when you are connected to the internet. I run it automatically from InJoy when I connect.
• To return a work unit to the cache for another machine to process, run SCVRun.CMD REMOVEHOSTNAME. This is only needed for machines that are not on all the time or run more than one OS. See Sharing Work Units Between Machinesfor more details.

SVCache.* Files

There are some special files used in the cache directories:

• SVCACHE.OK

  Indicates the directory is a cache directory and is to be processed. SVCRun will attempt to process a valid work unit in the directory. SVCBuf will attempt to return finished work unit and get a new one. If there is no work unit in the directory, SVCBuf will attempt to retrieve a new work unit.

• SVCACHE.NO

  Put this in any directory that is not to be processed. This is mainly used if there are files in the directory that could be mistaken for a work unit. Or, if you want to keep a work unit.  Or, when SVCBuf creates it after processing a directory with SVCACHE.STOP in it.

• SVCACHE.STOP

  If this is found in a directory, the work unit will be completed by SVCRun. When the work unit is complete and SCVBuf is run, the work unit will be returned but a new one will not be retrieved to replace it. After returning the work unit, SVCBuf will rename this file to SVCACHE.NO .

• SVCACHE.START

  If this is found in a directory, SVCBuf will retrieve a new work unit for the directory. After retrieving the work unit, SVCBuf will rename this file to SVCACHE.OK so that SVCRun will process it.

• SVCACHE.HOST

  This file is created by SVCRun when it starts processing a work unit in a cache directory. See Sharing Work Units Between Machines for details of this file.

How It Works

There are two parts to running SVCache - processing the work units and processing the cache.

Processing The Work Units

When SVCRun.CMD is run, it will:

1. Scan through all subdirectories for a work unit to process.
2. Creates the SVCache.HOST. The machines hostname and operating system is recorded in the file.
3. Process the work unit until it is finished or CTRL-C is pressed.
4. Update SVCACHE.HOST to remove the hostname. This allows another machine to process the work unit if it isn't finished.
5. Wait 30 seconds before restarting this process. If you want to stop SVCRun completely, press CTRL-C before the 30 seconds is up.

SVCRun chooses a work unit that meets these rules:

• The work unit that meets the first of the following rules:

1. An SVCACHE.HOST file exists, and its hostname and operating system are the same as for the current machine.
2. The work unit that has been processed the most. This is determined from the state.sah file.
3. The oldest work unit. This is based on the file "work_unit.sah".

• One of the files SVCACHE.OK or SVCACHE.STOP is in the directory.
• If the file SVCACHE.HOST exists, the operating system must be the same as for the current machine.

The file SVCache.HOST records:

• If a work unit is being process
• The hostname of the machine processing the work unit
• The operating system that any processing was done under
• Some debugging information that can generally be ignored

Returning and Fetching Work Units

The other part in running SVCache is returning completed work units and fetching new ones. This is done by SVCBuf. When it is started it:

1. Waits the amount of time specified in the variable start_delay.
2. Changes to a subdirectory.
3. Checks if one of the files SVCache.OK, SVCache.STOP or SVCache.START exist in the directory. If none of them are there, the directory is not processed, and SVCBuf proceeds to the next directory.
4. If one of the files exist, SVCBuf looks to see if the file RESULTS.SAH exists. If it does, the work unit has been completed and is to be returned.
5. If the file SVCache.STOP exists, this means that once the current work unit is complete. SVCBuf will create a file called stop_after_send.txt. This tells SETI@Home not to retrieve a new work unit after returning the current one.
6. If SVCache.START exist, then a new work unit is to be retrieved for this directory. This generally means a directory is being added to the cache.
7. If SVCache.OK exists, SVCBuf checks for SETI@Home work unit files. If they don't exist, a new work unit will be retrieved.
8. Depending in the status found in the previous steps, SVCBuf runs SETI@Home to return the completed work unit and retrieve a new. This is run with the parameter -stop_after_xfer so that the new work unit will not be processed.
9. After running SETI@Home, SVCBuf deletes the SVCache.HOST file.
10. SVCBuf then moves on to the next directory.

Sharing Work Units Between Machines

A work unit can be processed by more than one machine as long as they:

• Don't try to process it at the same time,
• Run the same operating system, and,
• Have different hostname.

This means that if you have more than one OS/2 machine, they can process the work units from the same cache. And if you shutdown one of them, the others can finish processing the work unit.

To completely enable this, I run SVCRun.CMD REMOVEHOSTNAMEon my part-time OS/2 machine when shutting it down. This removes the hostname from the SVCache.HOST file. It is run from the XShutdown folder in XWorkPlace.

SETILog2.CMD

SETILog2.CMD is used to log the results of a processed work unit in a file to matche the format produced by SETILog. This is a CSV file that can be loaded into a spreadsheet or SETIWatch. SETILog2.CMD will also store the result, user_info and state SAH files for later examination.

SETILog2.CMD will take the following parameters:

• directory name - The directory where the SETILOG.CSV file is. It will be created if it doesn't exist. The default is the current directory.
• /NOBACKUP - Don't backup the SAH files.
• /NOLOG - Don't log the work unit to SETILOG.CSV.
• /? - Display help and exit.

Note: SETIWatch and SETILog are Windows programs to monitor and log SETI@Home work units. They are available from SETIWatch home page.

Running Under Windows

SVCache has been tested to run under Windows 2000 using the Regina Rexx interpreter. Version 3.0 beta was used. It should run correctly under any version of Windows that Regina supports, and that can run Windows command line SETI@Home client.

To use SVCache under Windows, you will need:

• Regina - This is now a Sourceforge project. There seems to be an error in the download link on this page (there's a button, but, it isn't a link). So, try this to get to the Regina filelist page. I used the V3.0 beta 2 install file.
• RegUtil - This is an implementation of the RexxUtil library. It's by Patrick McPhee and is available here.

You will need to install the two packages according to the instructions at the above web-sites or inside the packages and verify they are working. Then, running SVCache is the same as running it under OS/2, except that the programs are run through the Regina interpreter. So they must be run with a command like:

REGINA SVCRun.CMD

Note: I've done just enough with Regina to get this working on my laptop under Windows 2000. If you have any problems, I will see what I can do, but, if the problem is in Regina, I probably won't be much help.

Hints

• Keep the cache as small as possible. SETI@Home would like all work units processed and returned as quickly as possible.
• Automate the running of SVCBuf. Either have it run once a day when you know you are logged on, or have it automatically started when you connect. If there are no completed work units, SVCBuf will not do anything.
• If you run SVCBuf automatically when you connect to the net, set the start_delay variable. Use it to start the processing after your other initial network activities (such as retrieving your mail).
• Use SETIView/2 to see what directories are being processed :)

Other Stuff

Future Enhancements

• Allow parameters for hostname, proxy and others to be passed in as parameters or read from a configuration file.
• Get it running on Windows 2000. This should be a simple matter of installing REXX and running it, but I haven't had a chance to try.
• Better information display or logging. What is currently displayed, is mainly debugging information.
  
• Allow work units to be checked in/checked out. This is to allow a laptop, to share the cache even when it's not plugged into the network.
• Change licence to GPL or similar.
• Clean up the code. It's ugly, isn't it?

Known Problems

None!

Bug Reporting

If you find any bugs, please tell me at the contact address below. Tell me:

• version of SVCache
• OS/2 Version and fixpack level
• if there are strange results being displayed, zip up the SAH files for the SETI@Home process, and send them along.
• anything else you think is important

Version History

• 0.1.0 - 06/07/2001
  
  • First release to public
    
• 0.1.1 - 10/07/2001
  
  • Fixed bug: Had messed up the multiple machines code so that hostname wasn't being checked properly. This meant that more than one machine could process the same work unit.
• 0.1.2 - 19/07/2001
  
  • Change to using Directory function instead of CD. Seems to have solved the problem with multiple machines.
  • Slight changes to details displayed on the screen.
• 0.1.4 - 05/10/2001
  
  • Fixed Bug: SETILog2.cmd could fail when reading LOGGED.LOG file.
• 0.1.5 - 04/11/2001
  
  • New: Added parameters to SETILog2.cmd to turn off logging and SAH file backup.
• 0.1.6 - 01/03/2002
  
  • New: Writing host and operating system from SVCACHE.HOST.
  • Fix: Heading for SETILOG.CSV has changed.
  • New: Making changes so that it can be run under Regina in Win2000.

Note: This is a release history. Each file also has a change history included in the block comment at its start.

Copyright

Except for SETILog2.CMD, this is Copyright (c) 2001-2002 David Forrester. All rights reserved.

SETILog2.CMD is based on someone elses work. But, I've lost all references to who this is. If it's yours, please tell me and I'll either remove it, or, give you the appropriate recognition.

WARNING!

This software is provided as is. No warranty is given by the author, expressed or implied. Use this software at your own risk. The author assumes no responsibility for any damage from the use of this software.

This software is freeware which means that it is free for use and distribution.

Contacts

If you find any bugs, have any suggestions or simply want to say how wonderful or terrible SVCache is, drop me an e-mail