• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Anything Faster than SetiDriver?

Actually Setidriver is just a interface for the SETI command-line client.
The actual crunching is done by the client itself.

I am sure others can give you a more complete explanation. 🙂
 
If there was we'd all be using it. 😉

Seriously, it is the CLI Client that does the crunching and it is much faster than the only other alternative..the GUI Client. SetiDriver is only an interface that makes it easy to control the CLI Client. The caching feature is its most important function which has really come into play during the last 24 hours.

What YS said. 🙂

I took too long to check my spelling. Ha 😉
 
good thing i cached about 10 wu's...except my comp has went offline itself today....so i wasn't even able to do 1 wu....seeming that i was at work...and was unable to reboot it...speakin o that i better fix that haha
 
oh yeah:Q
is there a totally dos version of the cli.....cause it would have to run somewhat faster than having a gui like win in the background heh
 


<< oh yeah:Q
is there a totally dos version of the cli.....cause it would have to run somewhat faster than having a gui like win in the background heh
>>



that would be the CLI ( Command Line Interface)

Force
 


<< well...i'm just wanting to know.....if there is anything faster than the setidriver....for crunchin the wu's? >>




SETI driver has nothing to do with how long it takes to complete a WU, however I think SETI driver is dog slow in transferring over to next set of work unit. It takes like a few min to transfer a few completed work units just because there is considerable delay between each transmission instead of sending them in one big packet.
 
the command line version runs in a command prompt
the reason it wont work in dos, I am assuming, is that it needs the networking support of windows
 


<< oh yeah:Q
is there a totally dos version of the cli.....cause it would have to run somewhat faster than having a gui like win in the background heh
>>



You could try what I do.

Linux/Wine/CLI

getting around 4 hr average on a work unit on a XP1600 W 512 RAM.

Now if the would just optimize the unix CLI

Alric
 
Jerboy -
however I think SETI driver is dog slow in transferring over to next set of work unit. It takes like a few min to transfer a few completed work units just because there is considerable delay between each transmission instead of sending them in one big packet.

The way Setidriver works is that if you have it set to auto-transmit, once a WU completes it immediately starts working on the next one in the background while it tries to transmit the completed one. So it's not like your machine is sitting there doing nothing when it's transmitting, although you may think it is. 😉 It *is* actually running the next WU. If you want to have Setidriver hold the results and send most or all the completed ones at a specific time, then you'll need to turn off the auto-transmit and then find a good time to manually send the completed WUs in the cache.

And with respect to SETI and DOS - the current windoze client is just that - a windoze/win32 (32 bit) client, with the GUI requiring the interface (explorer.exe) to be there and the CLI (command line interface) only needing a DOS box within the context of the interface. DOS itself is only 16 bit and is not supported.
 
The reason I didn't code SETI Driver to do multiple, simultaneous transmits is that I discovered (by losing WUs during development) that the SETI Data servers would lose WUs when you do this. There needs to be some time between the start of each transmit. I coded in a 30 second timer to force a reasonable, but small delay. On a slow link, this timer expires before the transmit finishes, but you will see it on a LAN. If this timer expires while the transmitting WU is still in progress, SETI Driver changes that process to "High" priority. This doesn't interfere with other processes in the system because the client spends most of it's time waiting for data and spends very little CPU time. This setting allows the transmit to occur at "network" speed, regardless of the priority setting of the SETI Client (or clients) that are actually processing a WU.

As Poof said, SETI Driver will start another WU while it's transmitting. What she didn't say was that on "Auto Transmit", SETI Driver starts the next WU before starting the transmit.

Mike.
 
Back
Top