:: 16-Jul-2000 23:02 (Sunday) ::

The pre-release process is back and its easier to find. You can now find
links to the pre-release page via the clients download page. So please if
you like helping out and want to find bugs that we missed check out
http://www.distributed.net/download/prerelease.html.

With that said the following clients have been placed for pre-release:

– Linux [alpha/ELF] v2.8010.463 2000-07-16

– AmigaOS [m68k] v2.8010.463 2000-07-16

– AmigaOS [PPC/PowerUp] v2.8010.463 2000-07-16

– AmigaOS [PPC/WarpOS] v2.8010.463 2000-07-16

The Following Personal Proxies have been placed for pre-release:

– Linux [alpha/ELF] v318 2000-07-16

Enjoy and remember to always report bug at http://www.distributed.net/bugs/

:: 15-Jul-2000 17:07 (Saturday) ::

Sorry about having stats offline for the past hour or so. It seems that
due to a screwup last night, the 14-Jul stats were duplicated for both
13-Jul and 14-Jul. I re-ran everything and the new numbers seem to be
accurate.

We are working with completely new code for ogr processing, which is why
we’re having these little glitches. The new code is much cleaner than
the old stuff, though, so in the long run the move will be extremely
worthwhile.

Another nice benefit of the new code is that we’ve managed to isolate
configuration data from process data, which means that it’s now safe for
us to make the stats code publically available. Prior versions (rc5) had
sensitive data like sql passwords and the location of the log server
embedded making its release impossible.

http://cvs.distributed.net/ is a browsable public cvs site using Bill
Fenner and Henner Zeller’s excellent cvsweb.cgi script. You can find the
stats code (both html and processing) as well as few other minor bits of
code.

The code is ugly, but I figure if CmdrTaco is brave enough to release his
slashdot code, then the least we can do is make this stuff public. :)

:: 15-Jul-2000 03:50 (Saturday) ::

I wanted to update everyone as to what’s going on with stats, since they’ve
been off and on all afternoon. We’ve been working hard to squash a few
OGR bugs that we found. When we were doing updates, we were shutting apache
down so that we wouldn’t have to try and fight all of you for CPU time
and disk bandwidth. }:8)

RC5 stats are running right now, and I’m also trying to debug another OGR
error, so apache will probably be off for a bit longer. I’ll turn it back
on as soon as I can.

Thanks for your patience while we work out these last few kinks!

:: 14-Jul-2000 20:31 (Friday) ::

The following proxies have been updated/added:

– Windows 95/98/NT/2000 (x86) [318]

See the list at: http://www.distributed.net/download/proxies.html

This version will tell clients v2.8008.459 and before that the OGR contest
is closed. More Proxies will be coming shortly.

:: 14-Jul-2000 12:41 (Friday) ::

I’ve updated the client speed pages to all output more concise results by
averaging all data for a single CPU/MHz combination. Additionally, the
standard deviation and a percentage representation of the stddev relative
to the avg is also displayed, to allow the entries with particularly bogus
entries to be more easily spotted. Check it out and add your client’s
benchmarked speeds today! http://n0cgi.distributed.net/speed/

:: 14-Jul-2000 07:55 (Friday) ::

Just in case anyone is wondering where the rc5 stats are, we started the
statsrun late due to work on OGR stats. The run also seems to be taking
more time than normal, possibly due to OGR contest start today. They should
be up by morning though.

:: 14-Jul-2000 07:19 (Friday) ::

A common question that I’ve been asked is what size the client actually
uses when you leave the block size setting at its default value of “-1”.
As it turns out, the built-in default is 2^30. You can see this by checking
the PREFERREDBLOCKSIZE_DEFAULT that is defined in client.h in the public
client source code.

However, even when you leave the client configured to the default size of
“-1” (or configure a larger block size), it is still possible for you to
receive the small 2^28 sized blocks. If that is the case then there is
nothing for you to be concerned about, since the servers would already be
trying to assign you a block size that most closely matches your request.
Receiving blocks smaller than what your client requests is frequently
common because that is the only block size available after the heavy
key-space fragmentation of so many other people explicitly requesting
smaller sized 2^28 blocks.

And just a reminder for anyone that may have too busy with all of the
recent activities and forgotten… July 15th is Cow Appreciation Day!
Blue-mountain offers us the following description: Started in Woodstock,
Vermont, Cow Appreciation Day involves many cow-related activities, such
as butter and ice cream making lessons, and dairy education programs. For
those unable to attend, it’s an excellent time to reflect on the important
role that cows play in all our lives.
http://www.bluemountain.com/eng3/susie/UNHudderly.html

:: 14-Jul-2000 03:17 (Friday) ::

Just tossing this inconsequential plan update in the middle of all the
more relevant news regarding ogr… I finally got the filter set up to
strip out all the gazillions of blocks done by the trojan client that used
my email address. It was a fun ride while it lasted, but I’m back down
to my natural keyrate now. (and pretty much entirely converted to ogr,
too)

Oh, and congratulations to jenson@medisg.stanford.edu whose PPC Mac turned
in the first ogr block at 22:54:57 13-July-2000.

:: 14-Jul-2000 00:36 (Friday) ::

The following clients have been updated/added:

– Windows 95/98/NT [x86/Installer] v2.8010.463b

By Date: http://www.distributed.net/download/updates.html

By Sys: http://www.distributed.net/download/clients.html

Changes.txt: http://www.distributed.net/download/changes.txt

Enjoy!

:: 13-Jul-2000 23:40 (Thursday) ::

For those of you running pproxies, please make sure that you deleted your
old OGR buffers from the last OGR project, which was suspended February
22nd. The pproxy will *not* automatically dump OGR work units from the
last time OGR was running. The old buffers will contain much larger stubs
which take a long time to process. With how fast OGR moves, it is possible
that any old blocks would end up as dupes, meaning that work would be
wasted.

Sorry for any inconvenience. }:8)