:: 31-Mar-2000 17:28 (Friday) ::

Hmm, it seems the planmailer still had a weird bug. Hopefully fixed now!
(for the ones not subscribed to plans@lists.distributed.net, this bug
caused all plans since the beginning of this system to be mailed out.
And in case I didn’t remove this bug completely, we now check for the
mailings not te be bigger than 10k in size, and if they are bigger, it
has to be approved by hand.

:: 31-Mar-2000 03:54 (Friday) ::

I’ve just been notified of and have verified a bug with the statsrun code
that deals with teams. The problem is that any participants who have been
‘removed’ from stats (this generally only happens when we find people who
have been installing the client without authorization) are still having
their blocks credited to their teams.

Due to the way we are processing the team ranking right now, it would add
a lot of time to the statsrun to fix this bug. There is a change planned
for the team ranking code that will both speed it up and fix this bug,
but it will be a little while before it’s implemented. I’m tired of breaking
the statsrun due to not being able to test changes, so this will wait
until we have a test database up and running. This is nearly done, so it
shouldn’t be a long wait.

Once this is fixed, I’m sure there’s several teams that will move around
in the ranking. I know it will be disappointing for the teams that will
suddenly lose a large number of blocks, but it isn’t fair to all the other
teams that these illegitimate blocks continue to be counted.

I will post another update before this change takes effect.

:: 30-Mar-2000 22:45 (Thursday) ::

Hi all,

Just a short line or two to tell you we just released another public source
package. This time we included MacOS-specific code as well as Dan Oetting’s
Altivec RC5 core. Happy compiling! :)

http://www.distributed.net/source/

:: 30-Mar-2000 03:09 (Thursday) ::

Errrr…. Uhmmmm….

Seems I made one tiny error in the change I made last night… }:8)

The insert to _master is running right now. Assuming my fix works as it
should, we’ll be good to go. I’ll know either way in a few minutes.

Assuming everything works, I’ll run the ranking for Mar 28 by hand, then
set the box loose on Mar 29. The Mar 29 run should be done about 8 hours
from now.

Hopefully, this is the last we’ll see of this problem! *crossing hooves*

Thanks for your patience.

:: 30-Mar-2000 02:47 (Thursday) ::

Silly me, I should have knocked on wood in my last .plan. The bug *is*
fixed as far as I can tell, but the box ran out of disk space last night.
In a comedy of errors, email on n0 was also down, so I didn’t get an email
informing me that the box was out of space. *and* our irc system monitor
was MIA. What’s that they say about things always coming in threes? :)

Stats are running again (just finished importing Mar 28)

nuts… just filled up a database device. This ain’t my week…

I’ll post an ETA once I have one. }:8(

:: 29-Mar-2000 07:58 (Wednesday) ::

Ahhh-ha!

*SQUISH!*

That’s the sound of me (hopefully) finding and squashing the bug that was
causing the statsrun to occasionally die. The query that does the append
into the master table was setup in such a way that if a person was on two
teams, then it would attempt to add two records to the master table, each
one containing blocks for the two different teams. Of course, you can’t
actually belong to two teams, so normally this shouldn’t be a problem.
BUT, if someone happened to switch teams while this query was running,
then the query could end up thinking you were on two teams. You would also
have to have submitted blocks on at least two occasions during the previous
day (I believe the query was essentially processing the data on an
hour-by-hour basis).

Hopefully you can understand why this was so difficult to track down. }:8)

:: 26-Mar-2000 01:37 (Sunday) ::

I’ve gotten some reports of inconsistencies in the number of blocks reported
to teams and the number of blocks reported in the team members listing.
I’m inclined to believe that this is due to the manual stats-runs that
happened yesterday. Stats are running right now, so hopefully all will be
well after the run is over.

On the good news front, Bruce is making steady progress on the OGR stats.
While it will be nice to have the OGR stats up and running, the real
excitement about this behind the scenes is that he’s taking this opportunity
to completely revamp the database structure for OGR. This will result in
less space being used, and faster stats-runs. Once we’ve tested the
structure on OGR, we should be able to move the RC5 data into the same
structure, which will result in much better, faster, and robust RC5 stats.

So, please bear with us… we are working to improve things, even if that
effort isn’t visible to most of the participants. }:8)

:: 24-Mar-2000 15:45 (Friday) ::

Yes, for those who’ve noticed, the stats for Mar 22 are MIA. Thanks to
the logging I put in the last time, I know where to start looking for the
problem. After I’ve looked into it, I’ll re-run Mar 22 and Mar 23.

Sorry for the slip-up.

:: 23-Mar-2000 04:35 (Thursday) ::

Hello! My name is Anthony ‘complex’ Elizondo. I’ve been with distributed.net
for about 6 months, doing mostly things that would be too boring to note
here.

My official title at distributed.net is officially Logistics Coordinator.
What it means is I mostly keep track of little things that tend to be
forgotten about, like accounting for distributed.net hardware donated and
in use across the world. It also entails finding people who might be able
to help distributed.net.

Right now decibel and bwilson are keeping stats running, but look forward
to revamping it to include multiple concurrent project statistics, greater
efficiency, and personalized stats pages. One area in which help is needed
is PHP coding. What follows is a job description for Lead Stats PHP Coder.
I encourage anyone with a bit of free time and the appropriate skills to
apply. Also, please pass this along to anybody you know who may be
interested. Resumes and cover letters may be e-mailed to
complex@distributed.net and/or decibel@distributed.net.

Lead PHP Stats Coder

Description: Oversight of stats PHP development and involvement in stats
development overall.

We are seeking someone who is highly skilled in PHP development. Immediate
need is to overhaul all of our PHP scripts to make them compatible with
a new database format, and to make them more maintainable. Long-range goal
is more features and a common set of PHP code across all of our projects.

Requirements: Experience with PHP required. Basic knowledge of HTML,
advanced knowledge (CSS, forms) desirable. Knowledge of SQL a plus.
Comfortable with peer review and brainstorming.

Commitment: 2-6 hours a week.

:: 20-Mar-2000 05:24 (Monday) ::

Ok…

Final internal client/proxy testing is going on. We are hoping to have
an open beta here soon. Please don’t mail me asking when, pay attention
to the web site.