[RC5] OGRs meet D.Net, was "sexy" projects

gindrup at okway.okstate.edu gindrup at okway.okstate.edu
Mon Mar 2 09:18:31 EST 1998

     OGR-21 might also serve as a decent testbed for the development of 
     v3 for D.Netters who felt like beta testing it during their parallel 
     I'd suggest a LGM or BEM for the OGR mascot.  (Woohoo.  USA: home of 
     the TLA.)  (Little Green Man)  (Bug-Eyed Monster)  (Three Letter 
            - Eric Gindrup ! gindrup at okway.okstate.edu

______________________________ Reply Separator _________________________________
Subject: [RC5] OGRs meet D.Net, was "sexy" projects 
Author:  <rc5 at llamas.net > at SMTP
Date:    2/28/98 12:32 PM

Thank you for the replies!  I am so glad to see that there is a large 
interest in OGRs.  I will attempt to reply to all of your questions in 
this one post...
> Jason, for those of us who are laymen (me), could you 
> please describe what an OGR is, and its application?  You 
> mentioned something about astronomy and astrophysics, but 
> not much more besides how big a problem it could be.
I am not actually involved in the project yet, so any explanation I 
could give would be an inaccurate regurgitation of what I've read on 
their main site (http://members.aol.com/golomb20/index.html).  You'd 
probably best go there for an explanation.  However, I can say that the 
exciting application of Optimal Golomb Rulers (OGRs) is that they give 
the absolute best placement for a certain number of radio telescopes. 
For example, the current 21-mark OGR search would give the optimal 
relative placement for 21 radio telescopes working together.  I think 
that's pretty cool!
> I think your estimate is a little high - here's a different 
> approach. The Golomb ruler search is *currently* progressing
> at about 1 trillion nodes per day (there is a little table in 
> the February 1998 update section on the Golomb home page,
> that's where I got this number). There are 80 contributors 
> listed at the top of this page, and this isn't too far off 
> from the actual number of contributors (let's just say 100 
> for a nice round number). With all of d.net's 20,000
> participants, that reduces the total amount of time remaining 
> to about *four days*. Even if only half the d.net participants 
> did OGR searches, and the average d.net participant only had
> half the computing power of today's average OGR participant, 
> that's still just two weeks. A month or two and it's dead for 
> sure.
<Greg Hewgill>
        Thanks for the insight!  This means that OGR-22 and -23 are feasible! 
> How is the current effort done?  If it's distributable, it
> can probably be adapted to work with our network (with v3, or 
> possibly a patched v2 depending on the way it works.) 
        They are currently doing everything by email, but they are working on a
automated distributed client-based system like ours.  Perhaps this is 
the *ideal* time to join forces...  ;)
> Are you associated with this project?  I have been looking at 
> their source for several weeks now and have been internally
> considering such an implementation.  However, I personally do 
> not have the time anymore to manipulate such code myself to
> build the necessary cores.  If you can arrange to have coders 
> related to the current Golomb coding please contact me, I
> might be able to get them started. 
<Jeff Lawson>
        I am not associated with this project... yet.  I only have one computer
and I don't want two idle-priority clients vying for my lone processor. 
I was thinking that I might switch over at the end of DES II or RC5-64, 
but if OGRs gets integrated with v3 as a core, then I will stay with 
D.Net and set OGRs at 50% of my idle time.
        I have only read their webpages and become excited about their
project.  As far as their coders are concerned, I think the next message 
should get your attention...
> A couple things about the golomb ruler search.  My name is
> Nate Begeman, and David Christie and I have written a pretty 
> darn good Golomb Ruler client for the mac based on a
> cross-platform core called GARSP.  The new client is not as
> dependant on processor power (although it is a factor) as bus 
> speed.  For instance, a 132MHz 604 used to do about 215,000
> nodes/sec. Now it does over 500.  The same goes with pentiums 
> and such.  And 64bit OS clients are running up to 5 times
> faster than before.
> My point is that Golomb is definitely a feasible project, and 
> one that could be completed well within a year.
> Happy cracking,
> Nate Begeman
> sampo at triton.net
        Thanks, Nate!  I think Jeff Lawson may be in touch with you about a
port to the D.Net architecture.  If not, you should definitely get in 
touch with him.  Imagine the acceleration your project would receive 
from involvement with D.Net on top of the acceleration recently felt due 
to your client!!  :-)
> Right now the engines are written in C, Just think how fast it 
> could be if someone like Andrew Meggs roled an assembly
> version : )
<Daniel Marcotte>
        Woah!  I can just see the OGR searches going through the roof now!  We
have so many accelerating factors!
        I really want this to happen.  I think the time is right, too.  There
is interest on both sides and the outline for v3 is being hammered out 
now.  That gives us time to develop the OGR core in parallel with v3, so 
when v3 comes out, the OGR core can be packaged with it!  That would give 
us at least three projects (RC5, DES, OGR) from which to choose for our 
individual clients to work on.  And they're all three-character acronyms! 
Go Bovine!  Moo!
Jason Bechtel
-Now all we need is an OGR mascot... preferrably one that makes a cool 
sound. :)
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net 
rc5-digest subscribers replace rc5 with rc5-digest
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list