[RC5] ogr - technical details
bwilson at fers.com
Wed Feb 16 17:20:16 EST 2000
-----BEGIN PGP SIGNED MESSAGE-----
I'll answer what I can:
|1. is there a count of nodes tested by the client inside the returned
I believe the logs generated by the pproxy and the client both contain
|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
|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
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
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
-----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