OGR=0?

[Engine]

I have a concern about what's become a common practice for those of us running RC5 only on the dnet clients. If we have everyone set OGR=0 on their clients in order to do RC5 only, what happens when RC5 ends? If we keep OGR=0 in all the inis, then the clients either a.) stop running all together or b.) keep crunching random RC5 blocks until someone comes along and either deletes the client or changes the ini file.

Wouldn't a much better solution be to keep OGR in there and set additional buffer level checking to 4? This causes the client to fetch more wu's from the highest priority project instead of switching to the next project in the list. When the first priority project closes, THEN the clients switch projects. This would have pretty much the same result as setting OGR=0, without eliminating a project completely.

This way, the only time it would switch would be on clients with intermittent internet connections that don't download enough wu's to last between connections. In these cases, the client would exhaust its RC5 buffers, and when it can't download any more it would work on OGR. Then, when the opportunity arises again it would download more RC5 blocks and continue cracking keys instead of nodes.

 

[Adul]

Hmmm so how would we go about that in the ini file? not following you

 

[Engine]

To do this, you would take the "=0" off of the end of the OGR in the project priority line in the ini.
So it would look kinda like this:
RC5,OGR,CSC=0,DES=0

Then, under the buffers section of the ini file, you would make it look like this:

[buffers]
frequent-threshold-checks=4

 

[TwoFace]

Yeah this would work Engine!

Nice thinking... I've circumvented the issue in another way for my home herd, but this is generally a better way What I've done for my home herd if anyone should be interested is I just don't DL any OGR to my pproxy thus my clients don't get any OGR work to do... when the need arises I'll just have to change one setting and all my cows would be cracking OGR

With love and respect your fellow TA member

Two-Face

 

[Engine]

TwoFace: Your way works great, too! My main concern was that people with remote assimilations that they can't really get to are going to have clients shutting down all over the place instead of moving on to the next project. Admittedly, it's probably a ways off yet, but it's still a valid concern With your way, though, it's just a flip of the switch to get everything running OGR once RC5 is done.

 

[Joe O]

Engine, I share your concern. We certainly don't need the demoralizing factor of having to scramble to change ini files when RC5 finishes. It would be great to continue the momentum of RC5 in OGR. As to how soon that will be, Who Knows? But statistically speaking, we are half done with the project. Explanation: We have checked approximately 1/3 of the keyspace with 2/3 left to go. We probably have to do 1/2 of that remaining 2/3, i.e. 1/3. As to how long it will take, thats something else. The contest has been going for 1093 days. Using the the average of the last seven days it will take 1094.3 days to exhaust the keyspace! So again, we are 1/2 done. Or 2/3 done, if we only have to do 1/2 of the remaining keyspace!

 

[JHutch]

Engine,

That's a good suggestion and I've already made the necessary change in the FAQ that will go on the TA web site!

JHutch

 

[Adul]

Bump

 

[Adul]

RC5,OGR,CSC=0,DES=0
[buffers]
frequent-threshold-checks=4


OK I think i got it

 

[Eug]

Or you could just switch to OGR now.



























j/k... I think...

 

[ZapZilla]

Does the =4 setting give preference to the project order listing?

If so, why set CSC and/or DES = 0?

 

[Train]

Zapzilla, because DES and CSC are both COPLETED projects, you want to NEVER do packets for those projects, the work would be totally wasted.

 

[CurtOien]

Please give this suggestion to Russ for his EZ install disks.
Thanks

 

[Viztech]

This is a good idea. For us OGR crackers, the opposite in project order would be the ticket.

OGR,RC5,CSC=0,DES=0

Personally, I use option 3 for additional buffer level checking, but I am on line 24/7.

viz

 

[sciencewhiz]

I agree with viz. I don't have rc5 disabled. I am on dialup and always connect before my OGR buffer completes.

It is even more important in OGR because there is no such thing as an OGR random.

 

[ZapZilla]

So after DES I all DES packets were wasted?!

Since DES included: DES I, DES II, and DES III, there just might be a DES IV.

Likewise, there just might be a CSC II or III.

Setting DES=0, CSC=0 will not allow a client to participate in any future DES or CSC projects.

Seems to me that if the =4 setting effectively prioritizes the clients according to listed order, then why cripple any unattended clients with =0 settings if there is no good reason not to?

 

[ViRGE]

The DES and CSC cores have been removed from all current clients. The only reason the commands are still there is because the client still makes a couple of refrences to it.

 

[Mark R]

The DES contests have finished, as far as d.net is concerned. The DES-IV contest if it goes ahead will require finding the key in such a short time (a few hours) that it will be impractical for d.net to attempt it.

The latest clients do not even include a DES core, or a CSC core for that matter.

 

[ZapZilla]

Thanks for explaining the good reason not to.