staff blogs

distributed.net staff keep (relatively) up-to-date logs of their activities in .plan files. These were traditionally available via finger, but we've put them on the web for easier consumption.

2009-07-27

bovine [27-Jul-2009 @ 23:26]

Filed under: clients,project status @ 23:26 +00:00

:: 27-Jul-2009 23:26 GMT (Monday) ::

Howdy folks,

We’ve just transferred some new clients from the pre-release page to the
official release page: http://www.distributed.net/download/clients.php

*dnetc511-amigaos-68k.lha
*dnetc511-amigaos-ppc-pup.lha
*dnetc511-amigaos-ppc-wos.lha
*dnetc511-amigaos-ppc.lha
*dnetc511-morphos-ppc.lha
*dnetc511b-dos-x86.zip
*dnetc511b-linux-cellbe.tar.gz
*dnetc511b-linux-ppc.tar.gz
*dnetc511b-macosx-ppc.tar.gz
*dnetc511b-macosx-x86.tar.gz
*dnetc511b-os2-x86.zip
*dnetc511b-win32-x86.zip
*dnetc511b-win32-x86-setup.msi
*dnetc510-linux-x86-elf-uclibc.tar.gz

As mentioned in a previous plan, these new x86 clients contain three
new OGR cores. Depending on your CPU type, the new cores may provide a
significant speed improvement over the cores used in previous client
versions.

Additionally we strongly recommend that users of OGR PowerPC clients
version 2.9103 or 2.9104 upgrade to these newer versions. It was
discovered that those two specific version numbers could process
OGR-27 blocks incorrectly, so results from those client versions have
been blocked. Users of PowerPC platforms should upgrade to client
version 2.9105.511 or later.

We have also promoted the following personal proxy binaries from the
pre-release page to the official release page:

*proxyper347-freebsd4-x86.tar.gz
*proxyper347-freebsd6-x86.tar.gz
*proxyper347-freebsd7-x86.tar.gz
*proxyper347-linux-cellbe.tar.gz
*proxyper347a-linux-x86-uclibc.tar.gz

We’re very close to being able to finally mark the first three
stubspaces for OGR-27 complete… The first one (OGR-27.1) was just
finished up in the last few hours. There are just a very small number
of stubs that we are waiting to be completed in OGR-27.2 and OGR-27.3.
We’ll make another announcement when those are finally received.

Keep on crunching! ]:8)

bovine [27-Jul-2009 @ 03:02]

Filed under: clients @ 03:02 +00:00

:: 27-Jul-2009 03:02 GMT (Monday) ::

Dear friends,

We have discovered our nVidia CUDA clients prior to v2.9105.512 had a
problem that would cause RC5-72 results to skip part of the
block. This issue turned out to be caused by a bug in the CUDA
compiler itself, which was fixed beginning in the CUDA 2.2 SDK. Going
forward we will only be releasing clients for CUDA version 2.2 and
higher.

The fixed behavior unfortunately reveals that new CUDA clients will be
about half the speed of the older buggy CUDA versions. We understand
that the apparent speed decrease will seem disappointing, but it’s
important to note the earlier speeds were not measuring useful
work. Going forward, speed comparisons should only be made with CUDA
2.2 or higher speeds, as these are the “correct” speeds. Also, please
remember the CUDA clients are still much faster than traditional CPU
clients.

If you are still running a CUDA beta client, we encourage you to
update to the current versions available on our pre-release page:
http://www.distributed.net/download/prerelease.php Results returned by
any earlier clients will no longer be accepted by our keymaster. Users
with prior stats credit from affected clients will not be
retroactively removed.

Due to aspects of our network communication protocol, we are not able
to remotely shutdown only the older, buggy, CUDA clients so we will be
implementing a method to send large, dummy blocks to older CUDA
clients instead.

Since all dnetc CUDA versions released so far have only been “beta”
clients with built-in expiration dates, the impact should be
contained. The last round of beta CUDA clients would have expired at
approximately the end of August 2009.

Thanks again to all of our beta testers that have been helping us
validate this exciting new technology.

2009-07-04

mikereed [04-Jul-2009 @ 12:26]

Filed under: project status @ 12:26 +00:00

:: 04-Jul-2009 12:26 GMT (Saturday) ::

Dear friends,

Since work began on OGR-27 in late February, more than 2% of the total work
necessary to prove OGR-27 is not optimal has been completed.

The first three stubspaces are nearing completion, and should be closed in
a matter of days. During this time, we will be periodically recycling the
remaining stubs from those three stubspaces, so it is important to avoid
excessively fetching more work than you can complete in about a week.

We have just started distributing work from the fourth and final OGR-27
stubspace. It is also the largest stubspace representing the remaining 98%. The
stubs in the final stubspace are more likely to vary greatly in size, compared
to those in the earlier stubspaces; however we expect them to generally be
smaller on average. If our estimation turns out to be proved correct, we should
be able to complete the remaining stubs at a faster rate than for the previous
stubspaces. As we are expecting that we will discover a better ruler for OGR-27
than the one we currently know to be optimal, we may not need to exhaust the
entire stubspace before discovering it. However, after the probable discovery
of a better ruler, it is possible that there remains an even better ruler or
rulers yet to be uncovered.

In addition, thanks to some excellent work by Craig Johnston, client versions
2.9105-510 and above contain three new OGR cores. Depending on your CPU type,
the new cores may provide a significant speed improvement over the cores
used in previous client versions. These speed enhancements will shorten
the time required to search the final stubspace. You are welcome to try a
pre-release client containing these new cores, which you can download from
http://www.distributed.net/download/prerelease.php. As always, please report
bugs using our bug database available at http://bugs.distributed.net/.

So load up those CPUs with fresh OGR-27 work, while enjoying an improved
noderate, and together we’ll crunch through the final stubspace with fury!

Thanks again for your participation!

Moo ]:8)