First, the easy question. Stop_after_send.txt is the method the SETI client uses to return a WU and not download a new WU.
Now the interesting question:
SETI Driver always fills the cache from the top (1 is the bottom), but this doesn't mean that WUs are processed from the top. WUs are actually processed in the order they were downloaded from the server. SETI Driver can, and does, mix up the cache when you are attempting to shrink the cache size. It does this to reduce the amount of disk IO it has to perform to keep the cache folders consecutively numbered. Here's an example
Your normal cache size is 10, which will take a PIII 550 3-4 days to complete.
You go on a week's vacation, so you set your cache size to 25 (just in case you get some RFI WUs that process quickly)
Transmit.
(assume WU 4 is ready to transmit and you're working on WU 3 - remember, we haven't changed the cache size since the initial transmit)
What SETI Driver will now do is the following:
for WU = 25 to 1 step -1
if WU is empty or ready to transmit, transmit
next WU
What you will end up with is a cache of older WUs in folders 1-3 and 5-10 (some may be new, but most will be older) and then new WUs in folders 25 to 11 and then the newest WU will be 4.
Go on vacation:
SETI Driver will process in order: 3, 2, 1, 10, 9, 8, 7, 6, 5, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14
You get back and are ready to return the WUs while SETI Driver is working on WU 13.
Set desired cache size to 10, creates the file stop_after_send.txt in WU folders 11-25.
Transmit
I will unroll the loop to make the expanation clearer:
WU 25 - Results return; no download
WU 24 - Results return; no download
WU 23 - Results return; no download
...
WU 14 - Results return; no download
WU 13 - Skipped; not complete
WU 12 - Skipped; not complete
WU 11 - Skipped; not complete
WU 10 - Results are ready. SETI Driver sees that WU 13 has a stop_after_send.txt file and moves it to WU 10. Results returned; no download
WU 9 - Results are ready. SETI Driver sees that WU 12 has a stop_after_send.txt file and moves it to WU 10. Results returned; no download
WU 8 - Results are ready. SETI Driver sees that WU 11 has a stop_after_send.txt file and moves it to WU 10. Results returned; no download
WU 7 - Results are ready. SETI Driver detects that there are no available stop_after_send.txt files. The client returns results and downloads new data
WU 6 - Results are ready. SETI Driver detects that there are no available stop_after_send.txt files. The client returns results and downloads new data
WU 5 - Results are ready. SETI Driver detects that there are no available stop_after_send.txt files. The client returns results and downloads new data
WU 4 - Skipped; not complete
WU 3 - Results are ready. SETI Driver detects that there are no available stop_after_send.txt files. The client returns results and downloads new data
WU 2 - Results are ready. SETI Driver detects that there are no available stop_after_send.txt files. The client returns results and downloads new data
WU 1 - Results are ready. SETI Driver detects that there are no available stop_after_send.txt files. The client returns results and downloads new data
At this point, the cache folders 8, 9, 10, 14-25 are empty
for WU = 1 to 25
if WU is empty, then delete folder
next WU
We now have the following folders: 1, 2, 3, 4, 5, 6, 7, 11, 12, 13; SETI Driver needs to renumber to fill holes. The renumber starts at the top:
13 -> 13 - 13 is currently processing; so we can't renumber it
12 -> 8
11 -> 9
The cache now looks like this: 1, 2, 3, 4, 5, 6, 7, 8, 9, 13
SETI Driver will add an empty folder 10, since that's what you asked for before the transmit session started
The WUs will be processed in the following order now: 13, 9, 8, 7, 4, 6, 5, 3, 2, 1
When 13 completes, SETI Driver will detect that WU 9 is the oldest WU and start it.
BUG ALERT: SETI Driver will "lose" WU 13 until after the next transmit. At which point it will renumber 13 down to be contiguous with the rest of the WUs, at which time it will "find" the completed WU for the following Transmit. You haven't lost a result, it's just misplaced for a short period of time. This bug is a result of a performance hack I implemented when it comes to counting the actual size of the cache. The cache compaction/cleanup routines use a more general, but slower, method to enumerate all the WU folders.
The upshot, to figure out the order of WU processing, do the following:
Open Search or Find Files
Search for the file work_unit.sah
Sort the results by "Last Modified Date" The oldest file should be the one currently processing.
Hope this helps.
Mike Ober.
