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.

2011-04-11

OGR-27 client issues

Filed under: clients,project status — Mike Reed @ 15:12 +00:00

Dear friends,

We are pleased to announce that we have recently identified and fixed some bugs in our OGR client codebase. One of them causes the client to skip part of a packet in very rare cases. It can happen only in OGR-27 and above, so previous projects were not affected. Fixes are included in our updated client, v2.9109.518.

Due to the severity of this bug, we decided to change the rules for stub verification. Now not only two returned results must have the same node count, but also at least one of the results must be returned by a fixed (.518) client. Thus we will be sure that no rulers were skipped. Since we have not started the second pass of OGR-27.4 yet, this is an ideal time to introduce a validation change like this.

We’re asking you to update all of your systems to the fixed client, v2.9109.518, as soon as possible. Results sent from older clients will still be accepted and counted in stats. Updating to the latest client will help us to complete the project faster.

The updated client also recognizes the new Intel Core i3 and AMD Phenom processors, which are becoming increasingly popular among budget-conscious consumers.

You can download the updated client for all major platforms at: http://www.distributed.net/Download_clients.

We thank you for your continued participation in this ground-breaking project.

Moo!

2010-12-28

A near-miss (or perhaps a near-hit?)

Filed under: project status — Mike Reed @ 21:00 +00:00

Dear friends,

We recently received the first true “false positive” work unit of the RC5-72 project. These are a rare find.

In the interests of client speed, only the first “block” of the encrypted text is decrypted and evaluated for a solution. This means that it’s possible for a key which isn’t the correct key to report as a false positive because although it doesn’t decrypt the text, it does yield a plaintext which matches “The unkn” for the first eight bytes.

The decrypt of the packet was “The unkn…O.k.V>..3W.R..lW.]*e.sc.:-…..u…..cN.&.0.N.” The lucky participant is known as 門村 (“Gate Village”) and will be receiving a T-shirt from us soon. He is a researcher in Japan running dnetc on a Windows system with a Stream client.

As some participants may recall, we also identified a similar ‘false positive’ during the previous RC5-64 project. Finding these are exciting because they help to validate that the project is working properly and is still on track to find the real solution.

It also represents an interesting datapoint regarding the RC5 algorithm. There’s been much speculation and napkin scribbling on just how frequently such false positives might present themselves. The general consensus seemed to be that such an occurrence is extremely improbable. A brute-force search is really the only way to conclusively determine the likelihood of such false positives.

Keep on crunching!

2010-07-09

mikereed [09-Jul-2010 @ 17:10]

Filed under: clients,project status — Mike Reed @ 16:10 +00:00

Today, we mark the passing of 500 days working on the OGR-27 project. By cosmic coincidence, it’s also Cow Appreciation Day today!

In other news, we have recently added new CUDA 3.1-cowpatible clients for Windows and Mac OS X to our pre-release page. Link

We thank you for your continued support.

Moo!

2010-06-29

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

Filed under: clients — Mike Reed @ 22:29 +00:00

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 — Mike Reed @ 13:18 +00:00

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-03-10

mikereed [10-Mar-2010 @ 00:28]

Filed under: stats — Mike Reed @ 00:28 +00:00

:: 10-Mar-2010 00:28 GMT (Wednesday) ::

Our stats system is down while we attend to some unscheduled maintenance. We
hope to have it back online shortly.

Thanks for your patience and continued support!

2009-09-29

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

Filed under: clients — Mike Reed @ 22:59 +00:00

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

2009-08-14

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

Filed under: clients — Mike Reed @ 22:30 +00:00

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

2009-07-04

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

Filed under: project status — Mike Reed @ 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

2009-01-29

mikereed [29-Jan-2009 @ 03:24]

Filed under: project status — Mike Reed @ 03:24 +00:00

:: 29-Jan-2009 03:24 GMT (Thursday) ::

Dear friends,

We are proud to announce that we have now completed 75% of the work necessary
to prove OGR-26 is optimal. The project is expected to complete within the next
few weeks, and we have already started preparations towards that project’s
successor. More details will be provided in the near future.

As you know, we recently published some pre-release clients that allowed our
early-adopters running high-speed hardware platforms to make use of larger
RC5-72 packets. As a part of this testing, our users have helped us to discover
that there is a bug in our stats tabulation code that counts these larger
packets as only one stats unit. We are fortunate that no stats credit has been
permanently lost. We will be correcting the bug and re-tabulating the affected
logs shortly.

As part of introducing large RC5-72 packets, we needed to update our proxy
systems to handle them. Unfortunately, a bug present in proxy build 346
invalidated a small number of work units by distributing blocks from subspaces
other than “CB”. This was spotted and resolved very quickly and we do not
expect that very many users received these invalid RC5-72 packets.

We thank you for your continued support and enthusiasm. We particularly
appreciate the work of early-adopters that are willing to help us test our
pre-release software and give rapid feedback.

Moo!

« Newer Posts — Older Posts »