:: 31-Dec-1999 01:29 (Friday) ::

I’ve updated the team info in the master tables to reflect what it was
yesterday. If the csc logs ever show up from the master, we’ll be good
to go. If they’re not in by 1:45GMT, rc5 stats will end up running, in
which case we’ll run the CSC stats afterwards.

:: 30-Dec-1999 21:14 (Thursday) ::

For all of you who want to know the gory details of what happened to stats
last night, here they are.

About a week ago, Sybase skipped a bunch of identities in STATS_Participant,
the main participant info table. This tends to happen when the server is
shut down abnormally, and has happened several times in the past. Unfortunately,
we didn’t catch it when it happened this time, so there were several days of
data with bad participant IDs. This meant re-writing the script we use to
correct this problem.

We re-wrote the script a few days ago, but hadn’t run it yet. Yesterday, Bruce
came up with a change for the statsrun code that would allow us to eliminate
the identity field from STATS_Participant, thereby getting rid of this issue.
Since this would also require rebuilding STATS_Participant, it seemed a perfect
time to fix the identity problem.

With the new statsrun code in place and looking good, I was ready to run the
re-identity script. I almost made a backup copy of STATS_Participant, but
remembered that the re-identity script made a backup copy on it’s own. Of course,
this breaks an axiom of computers that goes something like ‘Too many backups is
almost enough.’

The script had a minor syntax error, and in the process of trying to debug it, I
ran the script several times. This had the unfortunate side-effect of sending all
traces of STATS_Participant to the great bit-bucket in the sky.

Not to worry, we make weekly backups of the database for this very reason. With a
boatload of help from Nugget, we got a copy of STATS_Participant from Dec 27 back
into the database. Though, it took us three tries to figure out how to get it back
in without having Sybase redo all the identities.

Once that was in, we fixed the identity problem (making loads of backups along the
way this time) and pondered how to recover the participant data and team info that
had been changed/added to STATS_Participant in the past few days. We decided that
re-running those days from logs would be the easiest.

We extracted the days in question from the master tables and used that info to reset
everyone’s team affiliation to what it was for the 12/28 statsrun (a process that
ended up taking a few hours). We fired off the statsrun and waited. We had to fine-
tune Bruce’s code a bit, but things seem to be going well now and the 12/29 RC5 data
is just about done.

The only thing left to do is re-assign blocks for the past few days to the correct
teams for the handful of people who changed their team membership during those days.
Because that hasn’t been done yet, some of the team stats might look a bit off.
After tonight’s statsrun, everything should be back to normal.

I’m glad we won’t have this problem with STATS_Participants again! }:8)

Thanks as always for your patience and CPU time.

:: 30-Dec-1999 09:09 (Thursday) ::

It would appear that csc stats are up-to-date, although I admit I haven’t
thoroughly audited the numbers. We had to do quite a bit of “by hand”
data massaging during the recovery process, so I will take some time
tomorrow to sanity check the numbers. Stats had to be re-run from 27-Dec
to current.

rc5-64 stats are running now, and barring any problems will be on auto-pilot
for the next several hours. I’m going to take the opportunity to get
a bit of sleep and rest my eyes.

If there are any problems they will likely be related to team joining/team
changing during the previous three days. If you joined a team or change
teams recently, you might see some differences. (if you changed teams
on 28-Dec, the freshly-run stats will actually look like you changed teams
on 27-Dec). We should be able to correct these discrepancies tomorrow.

More info as we wrap up the repair. Thanks for your patience.

:: 30-Dec-1999 04:04 (Thursday) ::

blerg. Some days I wish I dug ditches for a living. :)

Still banging on stats, looking promising, but progressing slowly.

More info as the situation evolves.

Moo

:: 29-Dec-1999 23:54 (Wednesday) ::

Stats will be down for a while while I fix the participant ID overrun
that happened a few days ago. Anyone with a participant ID >= 500,000
will end up with a new ID as a result. This should only affect participants
who started Dec. 20th or later. All of your blocks and team affiliation will
be saved, the only change will be to your ID number.

I’ll post more info once everything is back online.

:: 28-Dec-1999 18:46 (Tuesday) ::

The following clients have been updated/added:

– dnetc-os2-x86.zip OS/2 [MMX-CSC] v2.8004.451

Changes:

2.8000
——

2.8004.451 fix: OS/2: Fixed crash in -config by using different API calls
fix: OS/2: included the forgotten CSC-MMX core.
fix: solaris x86: multithreading works correctly now (uses
native threads bound to LWPs instead of pthreads)

Enjoy
Moose

:: 23-Dec-1999 20:14 (Thursday) ::

Tracked down and squashed a particularly obscure authentication bug that
has been preventing some people from joining teams and/or editing their
participant information. As near as I can tell, the problem is completely
resolved now.

If you’ve been having troubles lately in authenticating yourself with
the stats server, give it a try now. Should work just fine.

As always, if there’s a problem, feel free to fill my mailbox. :)

:: 23-Dec-1999 07:01 (Thursday) ::

The following clients have been updated/added:

– dnetc-solaris26-x86.tar.gz Solaris 2.x [x86/MT/MMX-CSC]

The following proxies have been updated:

-proxyper311-solaris26-x86.tar.gz Solaris 2.x [311]

Enjoy!
Moose

:: 22-Dec-1999 18:38 (Wednesday) ::

I’ve just uploaded a new x86/Solaris client, which has the MMX CSC core, as
well as being multithreaded (fixes bug #450). I also uploaded a v311 x86/
Solaris personal proxy, which is CSC compatible.

Hopefully they’ll become available soon.

:: 22-Dec-1999 02:41 (Wednesday) ::

Some users have reported a perceived CSC speed drop between b2 and the
-450 release of the Mac client. Michael Feiri, the client’s author,
clarifies that this decrease is only perceived, and that there is no
actual decrease in crunching speed.

“AFAIR in the b2 version we didnt do any yielding during a benchmark,
but rather hogged the entire CPU. Now we do yield during benchmarks,
which is likely the cause for the performance decrease you have seen.
The actual CSC crunchers were left untouched between b2 and b9. So the
normal cracking in the release should be as fast as in b2 because even
in b2 we already yielded during normal crunching.”