[RC5] ogr - technical details

Kristopher Austin Kristopher.Austin at student.oc.edu
Fri Feb 18 00:27:15 EST 2000


My k6-2/400 is currently cruching on a stub for 19 hours now.  It says it is
only at 9%.  
First question:  Is the percentage anywhere close to accurate, since it
doesn't know how many nodes it will have to try?
Second question:  Does your 2 trillion number have any truth behind it or
was it chosen by random?  If true...On my k6-2 which benches at 1.85Mnodes/s
it could conceivably take 12.8 days to finish one stub.  I know that the
chances of having such a stub is slim, but this is possible.  At my 9% in 19
hours, assuming the percentage has any substance to it, I'll be cracking
this same stub for another 8 days.  
Third question:  Will this be a problem when we get to the final few stubs
and the ones that aren't returned yet are ones such as mine?  I assume not,
since d.net would just redistribute this stub to hundreds of computers
within an 8 day period and someone is bound to return it first.  I guess it
would just be sad news for the person that started it first and his computer
was just too slow.  He would end up not getting credit at all.
Just a few thoughts compiled from what I've been reading.  Let me know what
you think.

Raistlin

-----Original Message-----
From: Wilson, Bruce [mailto:bwilson at fers.com]
Sent: Wednesday, February 16, 2000 5:20 PM
To: rc5 at lists.distributed.net
Subject: RE: [RC5] ogr - technical details


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'll answer what I can:

|-----Original Message-----
|1. is there a count of nodes tested by the client inside the returned
|stub?

I believe the logs generated by the pproxy and the client both contain
this information.

|2. how much does (i like to have a number) the nodes/stub vary?

In a pathological case, a stub could abort on every ruler-measure it
tries to add on to the 4.  This would have a count of zero nodes.  It's
unlikely, but possible.  On the other extreme, it could be that none of
the short-circuiting would take place, and an extremely large number of
combinations would need to be tested.

The reality usually lies somewhere between, but the range is still
wide, say from 100,000 to 2,000,000,000,000 nodes per stub?  That's why
we can't say how much work each stub contains.

|3. how are stubs assigned by the proxies
|  3.1	may i discard stubs assigned by the proxy if i pulled too much
|of 		them? (unfortunately i supposed ogr stubs to be 
|completed equally
|fast 		as rc5 - now i am sitting on work for a year -> 
|what to do now?)
|  3.1 when will unreturned stubs be reassigned

As with other projects, I suspect we'll start at the beginning when we
get to the end.  The difference is, we can't shout "Eureka" and stop
when we find "the" answer.  The only answer is "no more stubs to test."

|  3.2 does the way stubs are assigned at a later time depend on the
|results 		of the returned stubs (since ogr has a 
|tree structure)

I believe (someone correct me...) the way we hand out stubs today is
the same as we will hand them out when we're at 99.9% finished. 
Finding a shorter ruler along the way won't save us the effort of
testing all the 4-stubs.

|  3.3 what information does go into the master proxy database? (or
|which 		information is stored in the returned ogr stubs)

The data in the perproxy logs is basically the same as in the master
proxies, I believe.

|4. stats might not come before ogr-24 is finished. ok, it's not easy
|to get a useful ogr stats and at least we know it might take a  while
|- this is fair. but will longer stubs be weighted more than shorter
|ones (i think this is the most important question for a stats geek
|like me).  

I appreciate your patience.  As it turns out, stubs are only useful for
distributing the information.  We're not going to rank people by the
number of stubs they return, but by the number of nodes they return. 
In this way, there's no penalty for getting "easier" or "harder" stubs.
 You get credit for the number of nodes eventually found, not for the
length of time it took.  A stub with twice as many nodes will take
twice as long, but give you twice the credit in stats.

One interesting side-effect of this is that your stats may be a little
more "bumpy" than you're used to.  If you're using a single PC, you may
not submit blocks for several days at a time.  People with 10 or more
computers will probably have smoother looking node-rates.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.1

iQA/AwUBOKswpvWcoJZUMLmVEQIQNwCeK2Y6jXFbvTSDF0pbVe9arGEh9D0An2Fz
u7nBC0uhuNFHga54TzelgTAQ
=vHxK
-----END PGP SIGNATURE-----

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