RC-572

[AQUAJOE]

can someone tell me what I am suppose to use to get the RC-572 stats to come up in my BOK signature stats.

[NeoGen]

You have to put in your number id and team glued together

example: 123456789Amd-Users

[AQUAJOE]

Thanks Neo!!

[NeoGen]

No prob Aqua

And by the way, same thing goes also for OGR25.

[Ototero]

Sorry Jeff, you've just been stomped :cry:

:D :D :D

[Lagu]

Hello

I have joined OGR and though to run OGR 25-P2. However, the client is running RC5-72??
Have I download wrong client? The agent is Win 32 bits V. 2911.496.
And how join AMDusers? It seems to be annoying or perhaps not. Shall I E-mail AMDave?
How got a username and password?

Lagu :?

[Empty_5oul]

no lagu leave it, you are correct

both are similar and run through the same client. let it run for now and dave will fill you in. basically you can sort that through the options - but it can be slow to update.

e.g. if no you say forget RC5 and only do OGRP2 it will finsih RC5 first though maybe switch every x hours. for new settings to kick in you really have to leave it on them for 48 hours before you can really see it is doing exactly what you want. Do not keep changing the settings etc as nothign happens instantly as that is when problems arise, lol.

when you get into it, the project is great. always has work and a server that is up (or mirrors you can connect through). the options also give you much freedom making it do pretty much exactly what you want.

[carlos]

Lagu,

Open your dnet.ini file and see if you have this:

[parameters]
id=your@email.com

[misc]
project-priority=RC5-72=0,OGR-P2

[ogr_p2]
fetch-workunit-threshold=1000

[rc5-72]
fetch-workunit-threshold=1000

[triggers]
exit-flag-filename=exit.now
pause-on-no-mains-power=no
restart-on-config-file-change=yes

[display]
progress-indicator=auto-sense

[buffers]
frequent-threshold-checks=1

If not add the lines you don't have. From now on you have the possibility to config the client just my editting the dnet.ini file. The client is config to download 1000 wu's of OGR and it will send automatically the completed wu's and keep always the buffer full.

To add yourself to AMD Users team go here:

http://stats.distributed.net/team/tl...ow=1&limit=100

And make a search using your email as participant. Then click on your name and then an option will appear to retrieve a password by email. Wait for that email. The password will give you access to your personal page. Then you can join AMD Users.

Carlos

[Brucifer]

1,000 work units seems like way too many. In reading the stuff for setting up a personal que, they recomment 4 days worth, otherwise you start pushing the envelope before they (distributed.net) start resending the work units out again, and the first one that completes that work unit is the one that gets credit.

If you get bored some time, keep total track of the # of work units you crunch, and the number that is reflected in your posted daily totals and you will see that you are not getting credited for every work unit you crunch. The differench is the work units distributed.net sends out waiting for the first return. I run buffers of 400 for amd64-3200 on linux. An xp1800 will crunch out just under a hundred or so a day, I'm getting around 90 a day out of xp1800. I keep my buffer file at the 300 level for xp1800's and that gives a 3 day run, just in case there are hickups from the distributed.net servers.


edit: extracted from the perproxy setup file,

Specifying numbers that are too large may cause your proxy to buffer a more blocks than your installed client-base can use in a realistic amount of time. It is important to avoid fetching too many extra blocks to reduce the likelihood of a large number of blocks getting wasted if your proxy crashes, or you decide to discontinue running a proxy. Additionally by buffering a large number of blocks, you increase the number of outstanding blocks that must be tracked and managed by the key distribution system, which limits many aspects of distributed.net's performance. On the other hand, specifying too few blocks will make it more likely that your clients will run out of legitimate blocks should short-term network outages occur, forcing them to compute randomly generated blocks, which would have a greater possibility of being duplicated by other machines.

In general, it is recommended that you buffer no more than about 3 or 4 days worth of blocks, so that you could potentially withstand a network outage that long in the worst case. There is typically no reason to want to buffer any more blocks than that. The appropriate number is of course dependent upon the number and speed of clients that you have connecting to your personal proxy, so you will have to determine this value experimentally.

[vaughan]

My P166mmx is set to cache 2 RC5-72 units and 1 OGR25-P2 task :shock:
It usually manages to crunch that in about 24 hours or so.