Q? about command line switches. (Maggi?)

[HedsSpaz]

I went back through and looked at that optimizations thread and was trying to figure out how exactly Maggi set the batch file up. I've figured out the first batch file, but the send results batch file has me a little confused. What I want to know is what the -stop_after_xfer option does. Now presumably it uploads the result file, but what happens next. Does it download a new WU, or is that where it stops.
What I'm trying to figure out is how to replenish the work units. It looks like what happens is that you go through and proccess all of the the units without uploading them, and then you run the next batch, which uploads them. Then what?

Help would be much appreciated, thanks all.
Ian

[CharlesWA]

The -stop_after_xfer option uploads your completed work unit and then downloads a new one. It then stops.

[HedsSpaz]

Thats exactly what I wanted to know.

Thanks much Charles!

[CHHAS]

The way my batch files work, is that the first is running with the -stop_after_process switch and then changing to the next dir, from 1 to 25.
The second, which uploads the units, starts with the dir before the current and then runs backwards through the dirs uploading until I stop it, this way it doesn't have to run through a lot of dirs without WUs to refresh.

[Maggi]

yup ...

and to work around a bug in SETI, when you're continously online you should split your batch to

seti.exe -stop_after_process
seti.exe -stop_after_xfer

because then it'll be restarted for each WU and won't cause a resource hog.

Cheers,
Maggi

[Rattledagger]

Maggi, if I understand you correctly, you will use only one batch-file with both -stop_... after each other then you're always connected. I can't see any reason for this, but then again if I dig out my win9x-copy, it doesn't run the cmd-line so I can't check out the resource-bug.

First, two facts:

-stop_after_xfer stops after uploading result/getting new wu.

-stop_after_process processes already downloaded unit, and stops. BUT if the wu is already done or there isn't any wu, seti@home tries to connect and upload the result/gets new unit.

The main reasons to use batch-files is:
1: cache units if you're not always connected.
2: cache units for future connecting problems.

As a measure against 2, I would still use two batch-files, even if I was always connected.
If you're never with the machine, you can just set the last line in process.bat to start upload.bat, and the opposite in upload.bat.

If you don't want to cache units, but wants to circumvent the resource-bug you can:
3: Use only -stop_after_process in a bat-file, or
4: Use SetiLog, or
5: Don't use win9x.

[Maggi]

Ok, maybe I wasn't very clear ...

At work I use a double P3 running WinNT and being connected to the net 24/7.
Upon startup I launch two batches for SETI which do the following:

:seti_render

Seti.exe -stop_after_process
Seti.exe -stop_after_xfer

goto seti_render

Before I knew about the resource hog, it looked like this:

:seti_render

Seti.exe

goto seti_render

The latter would restart SETI only if some error occured and thus would probably run for weeks and hence slowdown the system (because of the goto-loop). The version I posted first will guarantee two restarts of SETI for every WU and hence would not cause slowdowns while crunching.

At hime I run the CMD line version under W98 and generated a script for caching and crunching 20 WUs in a row...

for rendering:

cd .\Kopie(01)
Seti.exe -stop_after_process
cd ..

[...]

cd .\Kopie(20)
Seti.exe -stop_after_process
cd ..

for sending/recieving:

cd .\Kopie(01)
Seti.exe -stop_after_xfer
cd ..

[...]

cd .\Kopie(20)
Seti.exe -stop_after_xfer
cd ..

Hope this clears up the confusion.

Cheers,
Maggi

[This message has been edited by Maggi@Home (edited 17 June 2000).]