• 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.

OGR is BACK!

M

Moose

Member
Greetings cows of the world!

Earlier this year, distributed.net began integrating the Optimal Golomb Rules project (http://www.distributed.net/ogr/) into its network. However, some clients were returning inordinately large node counts for completed stubs. When sharing buffer files between certain combinations of platforms, buffers were becoming corrupted.

New clients have been built with this bug corrected, and we are now ready to restart the OGR project. On Friday July 14, 2000 at 0000UTC, we will restart from the beginning of OGR-24, using smaller work units that can be turned around more quickly. When OGR-24 is complete we will move right on to OGR-25 and so on.

Although OGR code has been present in the dnetc clients since version v2.8002.446, no blocks will be accepted from versions prior to v2.8009.460. We ask that you update your clients (http://www.distributed.net/download/clients.html) to v2.8009.460 or higher. These clients have been available for some time now and you should take the time to upgrade as many systems as you can.

Even if you don't plan on participating in the OGR projects, you will want to upgrade your clients because of major network and buffer-management improvements. Check out the changes document (http://www.distributed.net/download/changes.txt) for a complete listof changes.

Stats have been completed for OGR and will be processed with the RC5 stats run on the first day of the contest. For information on changes to stats see http://n0cgi.distributed.net/~decibel/newstats.txt
 
There goes the neighborhood!!!! 😉

I'll make sure to have some OGR blocks ready as soon as possible. No idea when I can get the Stats up.

Jay
 
Holy (*^%&^!!

hehe, I rather thought there would be a bit more than 2 hours notice of the start of the contest, but here goes!! 🙂

Now the full might of the giantNT4vizmechthunderstorm shall be known! 😉

-Brian
 
If OGR is built in to the client, how do I disable it? I don't want it interfering with RC5.

Russ, NCNE
 
Russ there is a setting for project priority in the client so dont worry.

I'm sort of glad to see OGR coming back, as I think we have proven that 64 bit encryption is pretty hard at the moment. Considering you can get 128-bit encryption for IE I would say that encryption is secure considering the level of computing power available.

Dont know if I'll continue RC5 later or go straight in for TA in OGR.
 
I'm not concerned about project priority, I don't want it to run at all. I don't want it taking CPU cycles from RC5. Or, am I missing something here?

Russ, NCNE
 
Russ, if you run a personal proxy and you have it set up so that it has a fairly large cache of un-cracked blocks and set the client priority to RC5, then the clients should never have the opportunity to work on OGR.
 
Cool!

I happen to agree with vss1980 🙂 Not that Rc5 isn't cool and all but hey this thing with OGR is actually useful... Imagine 30 years from now when the biggest mofo telescope you've ever seen, with sensors placed all around the solar system, detects life somewhere else and you can say: hey when they calculated where to put those things I helped 🙂 Yikes... kinda cool (everything is purely speculation of course) 😀

NICE WORK DNET
 
Russ--In the project priority, just change the order of projects so that RC5 is first in the list. Then, as long as RC5 is going on, it will do RC5 ONLY since that is set as the primary project.
 
Russ in the clients Moose was refering to .460 and greater you have to set the priority to rc5 because ogr will run with a higher priority if you don't. In the config file under "load work precedence" set it to rc5,des=0,csc=0,ogr-0. That should take care of it.
 
Russ,

Make sure ALL your clients have this under the [misc] heading

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

The =0 disables that part of the client.

If it has -1 next to it, it will auto configure what it needs for that contest.
Not good for just doing Rc5.

Doohhh CLL beat me to it. 😱
 
Russ (and others who are fairly new to DNet), when they change contests, the DNet Keyservers will modify the blocks (probably a single bit) that tell all PProxys and all Clients that the contest has begun. If they are using the default contest priority (DES, CSC, OGR, BRC) then the clients will stop RC5 when the block they are working on is finished, then switch to OGR. PProxys will start buffering both types of blocks, and it will be up to the clients to ask for what they want. To modify your clients to only ask for RC5 isn't hard, but may be time consuming.

If you are running your own PProxy, and you don't want it to ever tell your clients that OGR is available, add the following line to your "proxyper.ini" file at the bottom of the OGR section. Your PProxy will never ask for OGR blocks and your clients will munch on RC5 because they will be told that OGR isn't running. (btw, this is how it SHOULD work)

[ogr]
contestclosed=1

Good Luck. Me, as my DNet stats have said for months and months and months, Wahoooo for OGR!!!!!!!!!
 
What is this going to do to our team? If everyone is now switching over to OGR because that is the default.. what happens to the team?
 
RUSS(and all other fellow pproxy users): contestclosed=1 seems to revert back to 0 every once and a while. my suggestion(what I'm using now) is to have max blocks set to 0 along with all the other settings for ogr(or any other contest besides rc5) and then set contestclosed=1. This should prevent it from ever even thinking about sendint or receiving any data for OGR.
 
i just noticed a bunch of OGR packets comming in on my perproxy, I come herer to see if anyone has posted anything and there it is! too bad I dont even want to touch OGR until RC5 is over
 
I wish we would have some kind of warning. I lost a ton of blocks because my crack rack has been refused by the server address I had it set to. Since the .ini and buff out files are stored in RAM on the nodes, and since it flatly won't connect since they went to OGR, I'm screwed.🙁

Russ, NCNE
 
Russ, at least you're helping out TA's OGR group 😉. You could have done work that didn't count for anything at all to do with TA.

Finally! I'm going to start cracking OGR, as I'm getting a bit bored with GF. Two useful projects at once, what's the world coming to? 😉

I almost feel sorry for you RC5 people, since you worked so hard to get into a position where you will quickly pass /. A lot of people will go over to OGR either by accident or on purpose, which means a pretty severe hit to your performance. 🙁
 
amok,

Not anymore; on this end anyway. All the machines and the rack have been re-configured to do only RC5. But, Two is on vacation right now, so I assume that his labs are doing OGR. Will be until he gets back.

Russ, NCNE
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top