Which client do SETI Classic crunchers use?

[Hurricane Andrew]

Just curious. I've been using the 3.08 client, but I hear the 3.03 version may be a tad quicker. Any thoughts?

 

[Geekling]

I also use 3.08. But I was told 3.03 is faster.

 

[Freewolf]

3.03

 

[JarrodH]

3.03 seems to be faster for me.

 

[Rattledagger]

In my experience, the best is to use v3.08 on VLAR and v3.03 on other wu. For me, using NT4 also gave a speed-boost on VLAR compared to using win2k...

 

[Hurricane Andrew]

Thanks for the replies. I think I'll switch to 3.03 and see if I notice any difference.

 

[Ken g6]

I use both! I worte a batch script that checks the angle range of work units. "VLAR"s, very low angle-range work units, <0.1 in my case, are faster on 3.08. All the rest run on 3.03.

 

[RaySun2Be]

3.03

 

[BadThad]

3.03

 

[Assimilator1]

3.03 ,its the fastest overall
v3.08 is about 15% slower on normal AR WUs which are the bulk of WUs

Though I see Ken_g6 has the best of both worlds!

Fancy sharing that Ken?

 

[Hurricane Andrew]

Originally posted by: Ken_g6
I use both! I worte a batch script that checks the angle range of work units. "VLAR"s, very low angle-range work units, <0.1 in my case, are faster on 3.08. All the rest run on 3.03.

I'm not going to get that fancy, given that SETI Classic is winding down. The general consensus seems to be that at least for the majority of WU's, 3.03 is faster, so I'm going to give that a whirl.

 

[Spacehead]

Just so you're aware, there is a slight security risk with v3.03 which you can read about here.

If you're running XP or 2K here's an easy fix:

On your system(s) that run SetiQueue, search for the "hosts" file using Windows Explorer.
(For Win XP/2k - c:windows/system32/drivers/etc/hosts)
Edit it in a text editor (notepad is fine) and add a line at the end like this:

66.28.250.122 shserver2.ssl.berkeley.edu
(The IP and the server name are separated by a space or a tab character.)

If every one of your clients transmits to your setiqueue system, then that is the only one you need to worry about. In other words, any system that transmits directly to Berkeley should have the line above added to the hosts file.

The exploit requires a spoof entry to be added to the DNS cache on the system transmitting wu's to direct requests intended for Berkeley to a different system. TCP/IP always looks to the hosts file before looking at DNS to resolve host names so adding the line to your hosts file will always direct requests to Berkeley's IP regardless of what's in your DNS cache.

BTW, i'm using v3.03

 

[Assimilator1]

Good point spacehead

Though I thought it didn't matter if you used SETIQ?

 

[Smoke]

Originally posted by: Assimilator1
Good point spacehead

Though I thought it didn't matter if you used SETIQ?

.... only if the Q you are using has taken the proper precautions!

 

[Assimilator1]

Err ,what was that?

 

[Smoke]

Quoting OhioDude:

Smoke --

On your system(s) that run SetiQueue, search for the "hosts" file using Windows Explorer. Edit it in a text editor (notepad is fine) and add a line at the end like this:

66.28.250.122 shserver2.ssl.berkeley.edu

(The IP and the server name are separated by a space or a tab character.)

If every one of your clients transmits to your setiqueue system, then that is the only one you need to worry about. In other words, any system that transmits directly to Berkeley should have the line above added to the hosts file.

The exploit requires a spoof entry to be added to the DNS cache on the system transmitting wu's to direct requests intended for Berkeley to a different system. TCP/IP always looks to the hosts file before looking at DNS to resolve host names so adding the line to your hosts file will always direct requests to Berkeley's IP regardless of what's in your DNS cache.

 

[Assimilator1]

Oh right,that fix! ,I thought you meant something special for SETIQ

 

[Ken g6]

Originally posted by: Assimilator1
3.03 ,its the fastest overall
v3.08 is about 15% slower on normal AR WUs which are the bulk of WUs

Though I see Ken_g6 has the best of both worlds!

Fancy sharing that Ken?

I shared it once long ago, and no one paid any attention. But I'm home now, seeing this thread, so I'll try posting it again.

BestSetiDr.bat:

rem Choose the best program to run SETI.
rem Name your 3.03 cli client "seti.exe" and your 3.08 client "seti308.exe"
:start
rem First, maybe, get a WU.
if not exist work_unit.sah goto getwu
rem Now check the angle_range
find "angle_range= 0.0" work_unit.sah
if errorlevel 1 goto normal
rem This is a VLAR.
..\seti308 -stop_after_process
goto nextwu
:normal
rem This is a normal work unit.
..\seti -stop_after_process
goto nextwu
:getwu
rem use "seti -stop_after_xfer -proxy x.x.x.x:yyy" if not using seti driver.
..\seti308 %1 %2 %3 %4
if exist stop_after_send.txt goto quit
:nextwu
rem Insert the following line if not using Seti Driver
rem goto start
rem Also remove all ..\'s in front of the seti calls:
:quit

The general idea is to use it from Seti Driver, though it could be modified if you don't use that.

To use it you have to select "All Files" in the drop menu instead of seti*.exe, and then select the batch file. The only problem I know it causes is that, if you stop seti driver, SETI itself doesn't stop. I suggest keeping your SETI windows visible when using it; otherwise you have to go to task manager to kill them.

Editbfuscating smilies

 

[Robor]

Old school 3.03 CLI client running as a service.

 

[amdxborg]

3.03 Here as well with SETI Driver and FireDaemon.

 

[Rattledagger]

Originally posted by: Assimilator1
3.03 ,its the fastest overall

Well, v3.03 is slightly faster when it comes to crunching 1 result, but when it comes to crunching enough results for 1 wu to get a validated result, v4.xx have no problems of winning. :evil:


BTW, how would a client averaging 1.76 h/wu on a p4-2.8GHz-HT-Prescott, AFAIK non-overclocked, compare to v3.03?

 

[Assimilator1]

Is that P4 running on BOINC then?

 

[Rattledagger]

Yes.

 

[Doc Brown]

3.03