:: 30-Aug-2003 00:03 GMT (Saturday) ::

I just talked with MattR; he’s not going to be able to recover the existing
database. We’ll be restoring from a backup as soon as it’s done bunzipping.

:: 29-Aug-2003 23:58 GMT (Friday) ::

MattR was able to get the database online again, so I now have copies of the 3
tables. This means that no data should end up lost out of all of this.

There are 3 options we have right now. First, we can attempt to repair the
existing stats database. MattR’s attempting this right now. The second option
is to drop the existing database, restore from the July 12th backup, and bring
in the updated information. The third option is for us to cut-over to stats
running on PostgreSQL, which is 95% done right now.

I’m playing it a bit by ear before deciding which way to go. Going to
PostgreSQL is very tempting, since we’ll need to do it in the near future
anyway, but I don’t like the idea of going to production when it’s not complete
and hasn’t been beta-tested.

Whatever happens, stats definitely won’t be up until tomorrow afternoon at the
very earliest.

:: 29-Aug-2003 20:09 GMT (Friday) ::

Blower is up and running again; apparently it died because the raid controller
freaked out after a disk failure. I’m still hoping to recover any data that was
modified last night, but if that doesn’t happen soon I’ll just go with what we
have.

:: 29-Aug-2003 15:59 GMT (Friday) ::

Looks like all the trouble is being caused by hardware issues. Moose is working
on getting blower up and running again, at which point I’ll have a better idea
what’s left to be done.

:: 29-Aug-2003 11:45 GMT (Friday) ::

As I feared, the Sybase stats database is corrupt. I have copies of all
participant data (team membership, retires, team and participant settings) as
of ~8/29/03 0:00 UTC. If I have to restore using this data, any changes people
made last night will be lost. I’m still trying to find a way to at least read
from the corrupt database, since only one table is corrupt. If I can do this,
no data will be lost during the restore.

Unfortunately, no matter which route I take, stats will be down for most of
today at a minimum.

More info as available.

:: 29-Aug-2003 02:40 GMT (Friday) ::

RC5 stats are still wrong, but I’ve turned access back on. Hopefully I’ll have
it fixed tomorrow.

:: 29-Aug-2003 00:38 GMT (Friday) ::

I’ve added a couple new clients on the pre-release page (NeXT and
NetBSD) and moved two earlier NeXT clients onto the release page.
http://www.distributed.net/download/prerelease.php
http://www.distributed.net/download/updates.php

There have also been a couple of reports of unauthorized client
installations in combination with a root kit, so I’ve added another
entry to: http://www.distributed.net/trojans.php

Naturally this type of behavior is very unacceptable and causes a
great amount of effort for those who need to rebuild machines that
have been compromised in this way. So please restrain yourself to
only running out client on machines that you have proper authorization
and permission to do so on.

In other news, as of this weekend the keymaster is now filtering old
OGR blocks from clients from version v2.8014 or earlier (as per my
previous plan).

:: 28-Aug-2003 21:41 GMT (Thursday) ::

The problems with stats are more serious than I thought. The table that stores
how much work each email address did on each day no longer matches the other
tables. I know that sounds rather serious, but that information can always
be re-created from the log files if it comes to that. I’m in the process of
loading in a backup copy of that table; hopefully it will allow me to fix this
with a minimum of downtime.

More info when available…

:: 28-Aug-2003 20:00 GMT (Thursday) ::

The RC5-72 statsrun bombed; I’m going to have to re-load today’s data, so
expect stats to be a bit late.

:: 26-Aug-2003 19:20 GMT (Tuesday) ::

As indicated on the stats page, we have now searched every OGR-24 stub that
we distributed to the network. There is still more work to be done before we
can declare OGR-24 finished, however.

(If you’re unfamiliar with how OGR searches work, you might want to visit
http://n0cgi.distributed.net/faq/cache/281.html)

The issue is that the stub generation for both OGR-24 and -25 has been
constrained very tightly; the 70 mark constraint that is in use is more
appropriate for OGR-21. In all likelihood if a shorter ruler exists it
would exist in the space we’ve already searched. However, we are not
confident that the present search space is sufficiently exhaustive for
scientific purposes. We’ve completed the pragmatic search but still have to
fill in the “brute” part of “brute force”.

One of the challenges inherent in OGR is that it’s not possible to predict
beforehand how long any given stub will take to test. Accordingly, the
total burden of a particular ruler’s search is not predictable. While
counting the number of remaining stubs is easy it is not a measure of the
amount of work which remains, especially since the remaining stubs are
smaller than the stubs that have been searched to-date. It is safe to say
that we’re well past 50%, and we’re most likely past 80 or 90%.

Obviously, finding out we’re still not done with OGR-24 is a disappointment
to all of us. It’s important to realize that the work that’s been done thus
far is valid and had to be done. Likewise, while the 77% shown for OGR-25
right now is also far too optimistic, the OGR-25 work being done is
perfectly valid.

We still have a considerable number of small stubs (length >70 at the 6th
mark) which we have not distributed to the network. This is because most of
these stubs would take only minutes or even seconds to complete. Once we’ve
determined how much work is left to do we will be able to decide how to
complete it. An early estimate indicates that the distributed.net staff
could check the remaining stubs. If this is not the case we would distribute
the work to the network, but we can’t do this until we can ‘combine stubs’
so that many stubs that would take minutes to complete could be grouped
together. This is the only way the network at large could reasonably process
these minute-long stubs.

We are currently working on an improved OGR algorithm. Because of the work
verification process we use, we can not mix the results of the new algorithm
with the results from the current algorithm. We will use the improved
algorithm to finish OGR-24. Once we have checked all OGR-25 stubs with an
initial length <=70, we will also use the new algorithm on OGR-25.