[plans] distributed.net .plan update

plans at nodezero.distributed.net plans at nodezero.distributed.net
Wed Sep 29 21:00:02 EDT 1999

.plan updates in the last 24 hours: 
decibel :: 29-Sep-1999 04:00 (Wednesday) ::

Well, our luck just seems to be against us as far as stats-box goes. As Nugget
mentioned in his .plan, we've tried a few more things, and they don't seem to
be working. And right now, I can't get to the Sybase online manual, so I can't
really try anything new right now. Fear not though, we still have a few more
tricks up our sleeves (my current theory is that Sybase is very unhappy that
we've nearly filled a couple of the database devices... note that these aren't
directly related to physical devices).

But, amidst all this stats-anguish, there is good news! Since many of you may
not have seen it on the stats main page today, here's the relevant bit:

33,195,551 blocks were completed yesterday (0.048% of the keyspace)
           at a sustained rate of 103,134,987 KKeys/sec!

Yes, you read that correct, and it's not an error. We averaged 103Gk/s on
Monday. To help put this into perspective...

To put this in perspective, this rate is 217 times faster than our first day's
rate of 475 *M*k/s. Even if you look to one month after the start of rc5-64,
when our rate had stabilized at about 8Gk/s, yesterday's rate is still 13
times faster.

And, for those who are dying to know, at 103Gk/s it would take us 4.9 years
to polish off the remaining keyspace.

So, even though stats box isn't too happy right now, our network is doing great!

nugget :: 29-Sep-1999 22:25 (Wednesday) ::

I massaged the stats database today.  Made a few changes which may or
may not correct our recent difficulties.

First, I gave us another 2GB of space in the stats database.  We were
getting a bit low (not uncomfortably so, but still...) on space in
the database and I figured that now was as good a time as any to 
make more room.  This puts us at 4GB reserved for data, 1GB reserved
for transaction logs.

Second, I completely re-built the main rc5_64_master table.  The old
table allowed for nulls in team field, and apparently it's a bit more
efficient if nulls aren't allowed in fields, so the new copy of the
table doesn't allow nulls in any field.  There's no functional difference
for us, since "team 0" is used to denote no team, and it's impossible to
have a null id, date, or block count.

A necessary aspect of rebuilding rc5_64_master was re-creating all the
indexes as well.

We won't really know if this helped until tonight's run (in an hour or
so) -- so cross your fingers.

with apache down, everything's running faster than it was, so I'm hopeful.

To unsubscribe, send 'unsubscribe plans' to majordomo at lists.distributed.net

More information about the plans mailing list