i'm confused about distributed.net client...HELP!

[Sunny129]

i download the ditributed.net client and i'm running it right now. i know i'm crunching numbers right now b/c the client says i am. but what exactly am i crunching numbers for? i thought it was for RC5, but now i'm not sure. at distributed.net, download links on the RC5 page and the OGR page are the same. is the same software used for all distributed.net projects?

 

[mechBgon]

If the text in the client box mentions "keys" then you're doing RC5-64. If it is talking about "nodes" then you're doing OGR (probably OGR-25).

 

[Sunny129]

ok it doesn't say anything about keys or nodes, but it does say "loaded OGR stub," so obviously i'm crunching an OGR work unit. but i thought i downloaded software the crunches RC5 keys. how do i get it to download RC5 work units?

 

[MereMortal]

http://www.teamanandtech.com/faqs/dnet/beginner/rc5_only.asp

 

[Joe O]

Sunny129,
Welcome to RC5 and OGR. Yes the client is the same for both projects. It is all controlled by the DNETC.INI file. The FAQ point you to the following line in the [MISC] section:

[misc]
project-priority=DES=0,CSC=0,RC5,OGR

The above line says to do RC5 first and then OGR when there is no RC5 blocks to work on. Putting OGR=0 says never do OGR.

In the FAQ you will also find out about specifying how much work to buffer. Your ini file will also have two other sections:

[rc5]
preferred-blocksize=33
fetch-workunit-threshold=330

and
[ogr]
fetch-workunit-threshold=1

For my machine these two say load 2 days of RC5 and only one block of OGR. Since I have to manually dial up, this keeps my machine working even if I don't get back to it in time. There is one other line I have in my [misc] section that is relevant

run-work-limit=-1

This keeps me from working on random RC5 blocks. This is a matter of personal preference. I find that random blocks do not get counted for me. I'd rather do OGR or have the client shut down instead of doing random blocks. You may not feel the same way.

Even if you have a permanent internet connection, you should buffer a few days of work. You can leave this go for a while, until you see what is needed.

Good Luck!

 

[Sunny129]

thanks for the info guys...

hey Joe, what do you mean you don't like to work on random blocks? random as opposed to what?

 

[Joe O]

Sunny129,
Random as opposed to downloaded. If your client runs out of work and you allow it, it will pick a block at random to work on. This is somewhat controlled for some clients by dnet. In my dnetc.ini file:

[rc5]
preferred-blocksize=33
fetch-workunit-threshold=330
randomprefix=113

the random prefix is changed by dnet when I connect to them. This controls the general area that the client would pick random keys from.

Everyone else running randoms will pick the same area. The first one to return the random block gets credit, the others nothing. Sometimes someone elses client will pick a random block that is assigned by download to you. Then when you submit your results, you will not get credit for it. This is not good. Now it is possible that 2 people will download the same block if the proxy misbehaves, but this is not likely. It is also possible for dnet to reissue the block if it has not been returned after some time. On occasion dnet says that they reissue blocks after 90 days. Other times they say that they haven't reissued blocks yet because it is a manual process. The truth? Try to return your blocks as soon as you can. Some people save up their blocks for a massive dump, but they are taking their chances. Even if dnet does not reissue the blocks, other peoples randoms will cut into the credited work.

Ok, you asked for the time of day, and I told you how to build a watch. <G> I hope this helps.

 

[Sunny129]

ok, i understand the concept of random blocks now. what i don't quite understand is how giving the blocksize and workunit threshold specific values acoomplishes this feat. and also, its been suggested to me not to DL too many blocks at a time b/c i'm always connected to the internet.

 

[Joe O]

"giving the blocksize and workunit threshold specific values acoomplishes this feat" By itself it doesn't. you also need the following line in your ini file:
run-work-limit=-1
right after the project-priority line.

"its been suggested to me not to DL too many blocks at a time b/c i'm always connected to the internet."
That's correct, up to a point. But you need to allow for outages. Do you run SETIQUE? SETIQUE and its equivalents are not needed, unless Berkely goes down or your ISP does. Is that not correct? Buffering more than one block at a time is also not necessary unless DNet goes down or your ISP goes down.

preferred-blocksize=33 says give me the biggest blocks available. It's less hassle to run the big blocks that have 32*2^28 keys in them than the small blocks that can have as little 1*2^28 keys in them. It's also slightly more efficient. At least include this in you ini file. It won't guarrantee all big blocks but it helps. The keyspace is currently very fragmented and DNet is handing out a lot of small blocks.

 

[Sunny129]

i run SETI@home, but i have no idea what SETIQUE is, and i have a feeling you're going to tell me that these two things have nothing to do with each other...anyways, my network rarely goes down, but i suppose if it did, i might want to have a few blocks to process in the mean time. what is SETIQUE?

 

[Joe O]

I'm an alien in SETI land. We're going to have to wait for a SETI person to wander in here.

AS far as RC5 goes, are you up and running now?

The next thing to do is to get all of your friends to run RC5. Especially if they are not running any distributed computing projects. If they are already running something, That's good. Don't pressure them to change. This is after all, an individual choice.

Again, Welcome to RC5/OGR.

 

[Sunny129]

yeah...i believe i made all the necessary changes to the dnetc.ini file...at least all the changes you pointed out. and my client is currently crunching RC5. i can get some friends to join the team eventually, but it might take a few days or weeks...anyways, i'm also currently running SETI@home and UD. will running all three together significantly slow my progress in all three projects?

 

[CADsortaGUY]

Sunny129 - I run SETI and UD on my main box (XP1600 OC'd a tad ) and they don't mind each other except that SETI takes the all CPU power so UD takes a few days to finish a unit. But from what I've seen - UD doesn't care about Units processed but rather some kind of time/points structure. I'm afraid running RC5 and SETI would not be a suggestion that I would endorse (like I have a say anyway) as both Seti and RC5 count units processed not time taken. So RC5 and UD = OK(unless someone knows something I don't) and Seti and UD = OK
So to directly answer your question...Yes it would take significantly slow your progress to run all three at once.

SetiQ is a SETI Work Unit caching application and is not necessary for most SETI people unless they have a LAN they want to cache units for or have "special" connection issues. I'd say that SetiDriver would be a better caching program for most people.

CADkindaGUY