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.

2010/06/29

mikereed [29-Jun-2010 @ 22:29]

Filed under: clients @ 22:29 UTC

It has come to our attention that a problem exists with some of the nVidia CUDA systems running on the Windows operating system. The CUDA system already released is up to version 3.1, while our dnetc application only supports up to CUDA 2.2.

If your graphics driver is designed for a higher version than this, the application will appear to run normally, but will send us junk results. One way to test if you are running a compatible version is to run ‘dnetc -test’. A working system should pass all of the tests.

When dnetc for CUDA systems loads, it shows a line that begins:- ‘nvcuda.dll Version:’. If the version displayed is 8.17.11.9775, your card will produce junk data (which our stats system will filter).

We hope to release a new version of the dnetc application that will support the CUDA 3.1 drivers soon.

We thank you for your continued support.

Moo!

2010/06/28

mikereed [28-Jun-2010 @ 13:18]

Filed under: clients @ 13:18 UTC

Howdy folks,

We’ve just transferred some new clients from the pre-release page to the
official release page: Download Clients

Solaris/SunOS [x86]
OpenBSD [x86/ELF]
OpenBSD [AMD64/ELF]
OpenBSD [Sparc64]
NetBSD [Sparc64/ELF]
FreeBSD [7.x/x86/ELF]
FreeBSD [8.x/sparc64]
FreeBSD [6.x/x86/ELF]
Linux [x86/CUDA-2.2]
Linux [AMD64/CUDA-2.2]
Linux [x86/Stream]
Linux [CellBE]
Linux [AMD64/ELF]
Linux [x86/ELF/uclibc]
OS/2 [x86]
Mac OS X/Darwin [x86/CUDA-2.2]
PC-DOS, MS-DOS [x86]
Windows 64bit [AMD64]
Windows 32bit [x86/CUDA-2.2]
Windows 32bit [x86/Zipped]
Windows 32bit [x86/Installer]
Windows 32bit [x86/Stream]

Moo!

2010/05/09

A bit past due….

Filed under: clients @ 17:25 UTC

Greetings everyone. I’d like to take the opportunity to introduce myself. My real name is Korey, and I’m one of distributed.net’s newer staffers. I’m going to be doing a lot of what I’m doing now – communicating with you, our users. Our new blogging system makes it quick and easy for the d.net crew to fire off updates about our projects. So expect more from me.

One thing I’d like to share with you now is some exciting news about out RC5-72 project. If you haven’t taken a good look at that project in a while, have a glance at it now. I’m sure you will notice something very different as of late – higher keyrates. What do we have to thank for that? In a nutshell, GPU based clients. That’s right, the ability to run the distributed.net client on video cards. Currently, several NVIDIA based and ATI/AMD based cards are supported. Client’s for use on video cards are available on our pre-release page.
As always, pre-release clients could have a bug or two, so if you find something, be sure to report it using Bugzilla.

So just how fast are these GPU based clients? FAST. For example, an ATI HD 5870 video card is able to crunch over 1.8 billion keys/second. Yes, I said billion. With a B. A high end CPU, say an Intel core i7, would be lucky to get 80 million keys/sec. And that’s on the high side of an estimate.

So, if you’re willing, head on over to our pre-release page, and download one of the GPU based clients.
Your continued support of distributed.net’s efforts is always appreciated; keep crunching!
-koremore

2009/09/29

mikereed [29-Sep-2009 @ 22:59]

Filed under: clients @ 22:59 UTC

:: 29-Sep-2009 22:59 GMT (Tuesday) ::

Friends,

We’d like to let our ATI Stream users know that we’ve posted an
updated Stream client beta for Windows. A Linux beta will follow
shortly. As with all our pre-release software, clients can be found at
http://www.distributed.net/download/prerelease.php. This version of the client
fixes compatibility issues with Catalyst drivers 9.9. However, there are still
several known issues with this beta. Known issues include:

The Stream client will not be used to its full potential unless
its priority is set =2 or higher. To achieve this, enter the client’s
configuration mode, and go to options 3,3 and change the value to “2”.

Graphical User Interface (GUI) lag is still heavy. While this isn’t an
issue with dedicated crunching systems, if you run the Stream client on your
primary computer, the lag may bother you. As a workaround, use the screen
saver mode to overcome this. A link to directions to enable the screen saver
can be found at the end of this .plan.

Sometimes, upon exiting, the client will not save the work unit currently
being crunched. This is cumbersome if you have been working on a large work
unit, say 64*2^32, as all work will have to be re-processed. As a workaround
here, you can enable the “checkpointing” feature. To do this, enter the
client’s configuration mode, and go to options 2,4 and choose a path and file
name for your checkpoint file.

There are on-going issues related to remote desktop connections to Stream
clients. It has been reported that using third party remote connection
software (VNC) overcomes these issues.

We are working on ironing out the remaining bugs in the Stream client. If you
have software development experience, a compatible ATI Stream video card,
and think you may be able to help with these bugs, please send an E-mail to
help@distributed.net.

We want to thank all of our early adopters for their help testing our
beta clients. Currently, the Stream client produces the fastest key rates
of any desktop hardware component. It is truly an exciting time here at
distributed.net!

Related Links:

* http://www.distributed.net/download/prerelease.php (Pre-release download page)
* http://bugs.distributed.net/show_bug.cgi?id=4222 (Bug for not saving work units)
* http://faq.distributed.net/?file=52 (Information on the checkpoint function)
* http://www.distributed.net/docs/tutor_clients.php#cl_confg (Screen saver set-up instructions)

2009/08/14

mikereed [14-Aug-2009 @ 22:30]

Filed under: clients @ 22:30 UTC

:: 14-Aug-2009 22:30 GMT (Friday) ::

Dear friends,

We have been testing distributed.net clients for nVidia CUDA-compatible cards
for a while. Several users have noted that they are quicker than standard CPU
clients at processing RC5 packets. Yesterday, CUDA cards contributed about 3%
of the total work processed for the RC5 project. This may appear small, but
over time, it is significant.

At about the same time as nVidia launched the CUDA system, AMD came out with a
competitor which it calls Stream. Thanks to some excellent work by our friend
Sla Chupyatov, we now have a client ready for testing on Stream systems.

If you run Windows 32-bit or Linux and have an AMD R600 or higher
graphics system (HD 2xxx or better) with the Catalyst 9.7 drivers (or
higher) installed, you can help us test it. We are interested to hear
your feedback. Clients are available from our pre-release page at:
http://www.distributed.net/download/prerelease.php. Please, continue to report
any bugs or issues to our bug database at: http://bugs.distributed.net/.

We would like to thank all of our dedicated early adopters for helping us with
testing.

PS: In order for your pre-release AMD client to achieve optimal key rates,
the priority should be set to “2” using the built-in configuration menu (3:
Performance related options).

Moo ]:8)

2009/07/27

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

Filed under: clients,project status @ 23:26 UTC

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

:: 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/02/24

bovine [24-Feb-2009 @ 17:26]

Filed under: clients,project status @ 17:26 UTC

:: 24-Feb-2009 17:26 GMT (Tuesday) ::

Howdy all,

We’ve just confirmed receipt of the last OGR-26 stub, thus marking
that project officially complete! We will try to publish who
submitted the most optimal and last stubs, once we confirm that they
don’t mind their identities being revealed.

You should already notice that fresh OGR-27 stubs are already
available on our proxy network. To work on this project, you will
need to be using the v2.9103 client for your architecture. If you run
a personal proxy, you should upgrade to build 347. As usual, you can
find them http://www.distributed.net/download/

If your platform doesn’t appear to have released clients available
yet, that may be because some are still on the pre-release page–we
hope to officially release them in the next couple of days. We
appreciate your patience.

Due to variations in complexity, we expect that OGR-27 will take us
significantly longer than OGR-26 did. It is difficult to provide a
precise estimate but one extremely rough guess is about 7 years,
assuming no increase in computing power and that our size estimation
sampling reflects the entire stubspace.

There is one thing that is different with OGR-27 than with our
previous OGR projects: we are confident that we will discover a better
ruler for OGR-27 than the one we know to be optimal currently.

So get your clients cracking! Thanks again for your participation!

Moo ]:8)

2009/01/27

snikkel [27-Jan-2009 @ 18:47]

Filed under: clients @ 18:47 UTC

:: 27-Jan-2009 18:47 GMT (Tuesday) ::

An updated tarball of our public source is now available at

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

This includes the work to improve the CUDA platform, initial work on the AMD
STREAM platform, as well as many different bug fixes and feature improvements.
See the change log in the docs directory for additional details.

bovine [27-Jan-2009 @ 05:22]

Filed under: clients,keyservers @ 05:22 UTC

:: 27-Jan-2009 05:22 GMT (Tuesday) ::

We’ve started upgrading our keyservers to build 347 of our proxy
software so that we can now offer large-sized blocks for rc5-72. This
will allow our clients to waste less time during network transfers and
block transitions. The need for this feature has become increasingly
apparent as our clients have become increasingly faster, particularly
on CellBE, CUDA, and ATI Stream hardware.

The first clients to support this will be version 2.9103-509, which
are just beginning to appear on the pre-release page for testing by
early adopters. The client has a new configuration option to allow
the preferred blocksize to be specified (a larger default blocksize is
automatically used for those three hardware platforms). While version
2.9103-509 is the first to officially allow configuration of the
blocksize, we are able to silently offer slightly larger blocks (size
16) to previously released clients on those three platforms as long
as the client is communicating with a proxy of build 347 or higher.

When the client connects to a keyserver or a personal proxy of build
347 or higher, the server will make a “best-effort” attempt to give
the client blocks of that size. If the server only has larger blocks,
then the server will try to automatically split a block to match the
request. The server cannot combine smaller blocks into larger ones.

Although the new clients and proxies are still only available on the
prerelease page for testing by early-adopters, we appreciate the
patience of those who would prefer to wait until the testing of these
clients are completed and they are moved to the official release page.

Thanks for your attention and participation!
Moo ]:8)

« Newer PostsOlder Posts »