:: 06-Oct-1999 22:06 (Wednesday) ::

The newest installer for the Win32 CLI client, that Bovine
mentioned in his recent .plan, has a few new additions to
help those of you that are use to the Win32 GUI.

This new installer gives you the option to install links
to the more common command line options; -config, -help,
and -shutdown on the Start Menu. For those of you that
install the client hidden, you can opt to not install
*anything* to the Start Menu.

It also puts these links, actually short-cuts with the
options built into the shortcut, into the directory that
you install the client to.

This new installer also gives you the option to put the
client in the Startup Group along with the option to have
the client start from the runservices line, hidden.
The Startup Group addition lets you start the client
minimized to the systray, not unlike the old GUI.

I hope these additions to the CLI installer helps those of
you that are having a hard time adjusting from the Win32
GUI to the Win32 CLI.

Scott Ludwig

:: 05-Oct-1999 19:49 (Tuesday) ::

It’s been a few days since the initial release of our new
self-installer packaging of the Win32 CLI client and we’ve received a
significant amount of good feedback. We’ve taken your responses into
account and have since released an updated version 2.7112.444c of the
CLI self-installer. The actual client is identical to the last one
(and that of the 2.7112.444b zipped version), however some aspects of
the installer have been improved.

Among the things that you may have noticed with our self-installer
Win32 CLI versions is the inclusion of my new “Log Visualizer”
utility. This is actually a separate application that implements all
of the log graphing functionality that was in the original Win32 GUI
client. In addition to improving a number of bugs in the Win32 GUI’s
grapher, since it is a separate application, you can even use it to
view your log files from other rc5des clients on other machines or
platforms. Making the grapher separate also allows you to conserve
memory by not requiring you to have all of the graphing code and log
data loaded while you have the client running all the time.

One of the other exciting aspects about the Log Visualizer is that
full Win32 C++ source code is available for it on our source code
webpage at http://www.distributed.net/source/ This allows experienced
coders to help out by making their own improvements to this valuable
utility and contribute their changes back to the entire
distributed.net community. I encourage interested participants and
Win32 developers and who have spare time to consider helping to
improve it. Inside of its source code distribution zip file is an
initial TODO file listing some possible areas of work. You can email
your modifications back to me and I’ll occasionally update that zip
file with all of the cumulative changes.

We also have a Java Log Visualizer currently in development and will
similarly release source code for it once it has minimal
functionality. We welcome efforts to develop similar utilities for
other platforms! Keep watching for more exciting developments!

:: 04-Oct-1999 13:31 (Monday) ::

It looks as if statsbox decided to be a bit mischievous this weekend
while dbaker and I were both out of town. Certainly nothing critical,
but it was a bit annoying. A strange set of circumstances deep within
a “shouldn’t happen” loop in the stats and logcopying code resulted in
last night’s stats run only incorporating 23 of the 24 logfiles from
the keymaster. Any blocks flushed from 3-Oct-1999 23:00 to 23:59 will
not be reflected in today’s stats.

These blocks will be processed as part of tonight’s run (but still as
3-Oct blocks, not 4-Oct). Sorry for the inconvenience. dbaker and I
are going to spend some time today hardening the log processing code
to ensure that this sort of thing doesn’t happen again.

:: 03-Oct-1999 16:32 (Sunday) ::

Hi all,

As you may know, we have a glibc problem with x86 Linux clients. If
the client is statically linked with glibc 2.0, it can’t resolve
host names under glibc 2.1. And vice-versa.
Previously, we had ‘solved’ the problem by providing two clients, one
for glibc 2.0 and another for glibc 2.1. This is confusing for most
people.

I want you to beta-test another client. This v444 client was build
and linked against glibc 2.1.1 on a SuSE 6.2 system, but this time is
was dynamically linked. I think this should solve the problem, but I
need people to test this client to be sure.
I’m particularly interested in beta-testers on glibc *2.0*
systems. Tell me if it works on your machine or if it doesn’t, but
please include as much details as you can in either case.

Here’s the url :
http://nodezero.distributed.net/~remi/rc5des444-linux-x86-elf-mt-glibc2.tar.gz
and the GnuPG signature :
http://nodezero.distributed.net/~remi/rc5des444-linux-x86-elf-mt-glibc2.tar.gz.asc

Note to i386 & i486 users : You will see a slight drop in performance
because we can’t link the 386/486 self-modifying core in a dynamic
client. If you want the best performance, you should stick with the
443 client.
We will continue to include this 386/486 self-modifying core in future
a.out and libc5 clients.

:: 02-Oct-1999 05:45 (Saturday) ::

Two quickies (I sound like CmdrTaco (http://CmdrTaco.net) from Slashdot
(http://slashdot.org) now):

First, the stats are currently set to start the stats-run at 1:45GMT
instead of the normal 0:30GMT or so. I’m guessing that this is just a
mistake, but I don’t want to screw with it while Nugget’s out of town,
so it’ll stay this way until at least Sunday night.

Second, I changed the countries page so that it now uses height and width
tags on all the little flag images. This means that the page will display
before all the images are loaded. It’s pretty neat to watch all the flags
pop onto your screen in a random order… of course, if you have a fast
link you won’t see the effect very well, but I guess that’s the trade-off
you’ll have to live with. :)

Unfortunately, I didn’t get the code changed before the stats-run was over,
so the main countries page will be lacking the new tags until tomorrow
night. If you just can’t wait that long, you can see what I’m talking about
at http://stats-decibel.distributed.net/rc5-64/countries.html .

:: 01-Oct-1999 18:53 (Friday) ::

Well, (knock on wood) it sure seems like statsbox is stable once again.
I broke the cardinal rule in troubleshooting and changed a bunch of things
at once, so we many never know which change (or combination of changes)
ultimately fixed the problem. At this point, I’m just happy to have the box
running smoothly again in time for me to go out of town this weekend.

The wife and I will be in Nashville this weekend and it looks like statsbox
doesn’t need any more attention for the time being.

A fresh start on monday when I return… time to turn my attention to the
multitude of stats bugs as reported at http://www.distributed.net/bugs/
and then we can get back into feature additions.

It also looks like functional ogr stats will be needed quite soon, so
that’s on the docket as well. I’d like to, at the very least, get all
the _raw stuff implemented and get cpu/os stats back before we focus
on ogr implementation issues.

And to Kevin Bentz, thanks for the Aerosmith CD. It was the soundtrack for
the statsbox recovery after I ran out of RATM music. :)

:: 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.

:: 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!

:: 28-Sep-1999 20:39 (Tuesday) ::

Note to self: SQL written while listening to Rage Against the Machine will
need to be cleaned up at a later date.

I’ve got a couple working theories on the stats slowdown, and some test
code to run some benchmarks. Unfortunately I noticed that the monday-
morning statsdb backup didn’t happen monday as it should have, so I’m
in a holding pattern as the tables bcp out to a safe place. As soon
as this is wrapped up I’ll get to run some time tests to see if today’s
changes fix the problem.

The “I searched for my stats and got nugget’s” problem is fixed. Most
of the php3 pages have defaults where they show id #1 or team #1 if no
valid data is provided to them. I made a change to psearch.php3 last
night that jumps straight to psummary.php3 if the search only yields
one email address. It seems that psearch was confusing a lot of people
who thought didn’t realize that they could click on the email address
and get to a full summary page. I screwed up when I made the change,
but didn’t notice when I tested it because (drum roll) I tested it with
my email address. In reality, it wasn’t passing the id properly to
psummary, but I thought it was because the default was me. oops. :)

It’s fixed now, and should be working just fine.

I’m pretty sure we’re on the right track, that the recent slowdown in
processing is triggered/exacerbated by the fact that as of last week,
normal stats viewing now touches the “big” rc5_64_master table. Until
we added phistory, no stats pages actually hit the main table.
As explained in decibel’s .plan, he disabled the phistory pages to see
if that would help. As you know, it didnt’, but that may very well be
because we missed a spot. The “today this participant did foo% of their
maximum” line also hits the rc5_64_master table, and we overlooked that.
So, you guys have been hitting the rc5_64_master table this whole time,
even with phistory disabled.

Assuming this is indeed the cause of the problem, I made changes to the
php3 code today which may eliminate the conflict. If the changes do not
help (and tonight’s run also takes way too long), the next step will be
to disable phistory and the “today compared to best day” psummary line
during the update. (not all the time, just when the update runs).

If that doesn’t help, well… we’ll burn that bridge when we come to it.

:: 27-Sep-1999 20:09 (Monday) ::

Finally have a chance to do some forensics on statsbox, I’m starting off with
the normal “dbcc checkdb” and “update statistics” just to make sure
everything is tidy at the lowest levels. I also see that we’re getting close
to capacity (only about 150mb free on the main statsdb device) so I’m going
to slice off another half gig or so of space for the data tables.

I think we’re within a few months of needing another drive in there,
the main RC5_64_master table is nearing 20 million rows.

The goal today is to determine the cause of the daily update slowdowns that
started last week, although I’d settle for prodding at the box and having it
automagically start working properly. :)