[RC5] ogr - technical details

Wilson, Bruce bwilson at fers.com
Wed Feb 16 17:20:16 EST 2000


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



More information about the rc5 mailing list