Ik weet niet of iedereen de mailtjes van de listserver van d.net leest. Maar er worden daar een aantal dingen op tafel gelegd die wel het einde van de bereidwiligheid voor OGR kunnen betekenen.
My memory was off on both counts. The only number I have is for for
OGR-25. I wouldn't trust anything d.net has to say until they stop
covering up the problems.
The distributed.net OGR code was derived from GARSP. The last ruler GARSP
ran was OGR-23 and that is all the code was good for. None of the
original developers of GARSP came along to help port the code so the
OGR-23 limits were never fixed for the d.net runs of OGR-24 and OGR-25.
The first problem to surface was an internal table was being accessed one
byte passed the end. This was first reported almost a year ago but was
soon dismissed when recompiling with different options allowed the client
to pass the internal tests. [All the clients running today are accessing
this invalid byte but they all pass the tests because the "valid" results
were also generated by the buggy code] Someone finally discovered the
fault was not a compiler error and at some point I was brought in because
I actually knew something of how the OGR code worked. It was still weeks
before this was even discussed on the coders list. I was waiting to let
d.net make the official announcement and I finally forced their hand by
posting a reference to the bug. I think this all transpired back in
Nov/Dec but don't trust my memory.
I was able to prove that even though this was a major bug the client
results were still valid. The bug was causing the client to work about
15% extra but no valid rulers were being skipped.
But then other bugs started being discussed on the coders list. The
thread safety problem was brought up where the buffer between the main
client and the core thread could get corrupted. A serious problem but if
it doesn't happen too often the invalid results can be filtered out in
the verification pass. Stubs were being truncated in checkpoints. This
only affected a few clients and cause some rulers to be retested when
restarting from the checkpoint. And then the reason we don't know how
many stubs there are is because the master stub generator was throwing
out all stubs with a total length greater than 70. This was valid for 3
mark stubs in OGR-23 but is totally wrong for 6 mark stubs in OGR-24.
I don't know what's holding up the new clients. The OGR code has been
fixed, the buffer problems could be patched with a simple handshaking,
the master stub generator needs to be rebuilt but it is essentially the
same code as in the OGR core. And somebody needs to explain to the users
why a year or two of crunching is going to be thrown out when OGR-24 and
OGR-25 are restarted.
I've tried to let the word out softly but my posts are being censored by
the d.net staff. You should switch your clients to RC5 until the new
clients are released so you don't waist more cycles. Or go hunt aliens
with Seti@home like I have been doing.
Ubero: #2, Euler: #1, GOT: #1, Des: #1, Zeta: #1, Eon: #3, OGR-24: #3, OGR-25: #7,
LM: #7, AP: #5, DF: #19, D2OL: #37, SOB: #50, TSC: #63, RC5: #96