Project News Update

[paleseptember]

From the .plan. Includes some info about random stubs from early subspaces (as has been discussed in other threads). Those who are interested are probably subscribed to the email listserv, but nevertheless!

bovine :: 30-Sep-2008 16:22 GMT (Tuesday) ::

Dear friends,

As you know, we are drawing to the conclusion of the OGR-25p2 project,
with less than 1% remaining and we estimate project completion
sometime within the next month. You can view the latest OGR-25p2
project percentages here:
http://stats.distributed.net/project/ogr_status.php

We have noted that a significant amount of work is not being counted,
due to being held out of the system for a long time and completed by
other users before it is returned. In some cases, it is returned even
after stubspaces have been closed. At the current stage of the
project, a workunit which isn't returned within two weeks of being
issued will have a high chance of being recycled and processed by
somebody else. This duplicated workunit will still be credited in
personal stats, but it won't have any value to the project.

One of the stubspaces currently open will take only two days of
concerted effort to close off. If we are to calculate at full
effectiveness, it is vital that work is completed and returned in a
timely fashion.

If your computer has a connection to our key servers or a local proxy
server, we recommend that you keep your client set to the default
buffer settings to avoid buffering an excessive amount of workunits.

Additionally, if your client is configured to participate in only
OGR-P2, we encourage you to consider enabling your clients to
participate in both OGR-P2 and RC5-72. Over the next few weeks, we
anticipate there being occasional periods of time when there will not
be any OGR-P2 workunits available, due to the recycle delays and
timeout periods. By enabling your clients to also process RC5-72, you
will ensure that your computers will not go completely idle during
these periods.

Finally, we would like to mention that we are currently finalizing a
next-generation OGR project that will further the exploration into
even higher-order Optimal Golomb Rulers. Stay tuned for more details
later.

We would like to thank you for your continued support and your ongoing
efforts to help us.

Moo! ]:8)

[alpha]

From the .plan. Includes some info about random stubs from early subspaces (as has been discussed in other threads).

Does it? I can't see that it does. I've been getting a few fresh stubspace 1, 2, 4, 5 and 6 stubs over the last few days and I'm definitely not hoarding or using stale buffers. My pproxy serves up to at least half a dozen computers and the cache size is only 150 stubs.

Finally, we would like to mention that we are currently finalizing a
next-generation OGR project that will further the exploration into
even higher-order Optimal Golomb Rulers. Stay tuned for more details
later.

GREAT NEWS!

[paleseptember]

I meant information insofar as the user will still get credit, even though they are not actually processing (or verifying) active stubs.

alpha: It's a mystery Unless it's a fault with the perproxy software or the perl script is misinterpreting some of the results? I don't know how either of those work, and I'm not intending to criticise the authors of either piece of software.

Should be an interesting last few days. I like that they've shortened the time-out period. I was imagining the project dragging out for another three months as the 90-day timeout period slowly elapsed (I don't know if it actually was 90 days, all efforts to confirm that have failed!)

Edit: Just noticed, this was my 200th post, hurrah! No relevance whatsoever, just thought I'd mark the milestone Only took me three years!