I have posted the status of OGR to this list in the past, but perhaps
it's time for a restatement.
Status of OGR
* The OGR client has a bug which weakens the accuracy of our results.
A truncation error causes rulers with many segments to be aborted
incorrectly. We were making some good progress towards fixing this bug
and releasing new clients when we solved RC5-64. At that point, all OGR
development was put on hold in favor of RC5-72.
Because of the verification plan we are using, we do not expect to have
to discard work done with current buggy clients unless the bug affected
the results for a given stub. Our original plan was to require two
identical results for the same stub from different participants. Now we
will be revising that to say that one of the results must also come from
a "fixed" client. If the buggy client gives the same results as the
fixed client, the bug was not a factor. If the buggy client gives a
different result, then we wait for a confirmation from a different
participant using the fixed client.
Status of OGR stats
* Progress is very hard to compute for OGR, relative to the RC5
projects. For RC5, we only need to track whether the work was completed
or not (a single bit of information). For OGR, it is necessary to track
what participant completed each stub (and now, we must also track
whether the client was pre-fix or post-fix). We also keep track of how
many nodes were found in each stub, to verify that the participants got
the same results. In all, the storage requirement per workunit is
orders of magnitude greater than RC5-64 - we go from one bit (1/8 of a
byte) per workunit to about 50 bytes. This is just the beginning.
In order to report on the progress of the project, we have to determine
which stubs have been completed once, and which have been completed
twice. This means verifying that the second submitter is different from
the first, and got the same result. While we had a mechanism in place
early in the project for calculating this, it was highly
manual-intensive, and took a long time to run. Somewhere along the
line, the database where these calculations were created has been lost
(I think I heard it was lost through disk failure, but that could be
wrong). Some work has been put into recreating this database and the
process that went into it, but this is not simple work, and the ones
with the specific knowledge have had very limited time. Again, the end
of RC5-64 drew our attention away from OGR stats.
Aldus Bruce Wilson op de distributed.net mailing list.
http://lists.distributed.net/hypermail/rc5.Oct2002/0061.html
Haal diep adem. telt tot 10.. en gewoon door grazen.
:strip_exif()/u/24180/weena.gif?f=community)
43)
3)
)
/u/748/turkey_watching_football2.GIF?f=community)
:strip_exif()/u/1873/nightbird_60.gif?f=community)
:strip_exif()/u/13938/head.gif?f=community)
