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.

2012/04/07

OGR-27 50% completion

Filed under: project status @ 23:09 UTC

Dear friends,

After three years of effort, we have passed the half-way stage of this ground-breaking project. We thank you for your continued participation.

Moo!

2011/11/27

Project status for November 2011

Filed under: project status — Tags: @ 18:26 UTC

This past week we passed two nice milestones for our current projects:
On November 21, 2011 we passed 2% completion of RC5-72. We also recently passed 1000 days of OGR-27 since starting it in February 24, 2009.

Long time participant Andrew Hime posted a nice summary of the milestone statistics to our mailing list, so I’ll avoid repeating further details and just link to his post:
http://lists.distributed.net/pipermail/rc5/2011-November/042080.html

Today we also started recycling some of the old RC5-72 subspaces. This means that we’ll be sending out blocks that had initially been distributed as long ago as 2002 but had never been fully completed by any client. Since these subspaces are already mostly complete (generally about 85% to 95% finished), we’ll be able to move through these subspaces pretty quickly. Once we finish this pass of the uncompleted blocks, we’ll resume distribution of blocks from fresh subspaces again.

As always, thanks for your participation and support! ]:8)

2011/04/11

OGR-27 client issues

Filed under: clients,project status @ 15:12 UTC

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/29

Wrapping up 2010

Filed under: project status @ 00:34 UTC

Dear friends,

With 2010 coming to an end, we thought this would be a good time to review the tremendous progress we’ve made this year, particularly on the RC5-72 front.

Modern video cards now typically include highly advanced parallel processors that can sometimes be used for general purpose computing. Although only certain types of tasks are currently suitable for GPU acceleration, we’ve found that RC5 falls happily in that category.

We began beta testing our first GPU-based clients for nVidia CUDA and ATI Stream in January and February 2009, respectively. Public testing of the GPU clients continued for about a year until we officially released both the CUDA and Stream clients in January 2010.

Adoption of the new GPU clients has been very successful throughout 2010, due in part to the folks at DNETC@Home. At this moment, about 86% of our incoming completed RC5-72 results come from Stream clients, 5% from CUDA, and 7% from traditional x86 processors.[1] Another exciting milestone is that the overall total results ever received for the RC5-72 project, results from Stream/Win32 are extremely close to surpassing those received from X86/Win32, despite the nearly 7 year lead before the official release of GPU clients.[2]

RC5-72 keyrate for 2009-2010

At the end of 2009, our overall RC5-72 project keyrate was about 250 GKeys/sec. Our current project rate is now about 1.5 TKeys/sec, or about 6 times faster than last year!

If we started RC5-56 right now (which took us 250 days in 1997), and found the key in the same place as last time, it would take us about 18 hours to complete. If we had to check the entire keyspace… it would be a little longer–perhaps 38 hours!

In the coming year, we hope to announce some other exciting developments which should continue to push the performance and awareness of distributed computing.

If you’re on Twitter, be sure to follow us on @dnetc!

Happy Moo Year! ]:8)

2010/12/28

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

Filed under: project status @ 21:00 UTC

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! ]:8)

2010/07/09

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

Filed under: clients,project status @ 16:10 UTC

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! ]:8)

2010/05/13

OGR-27 Progress

Filed under: project status @ 22:46 UTC

If you’ve been following our OGR-27 stats you’ll have noticed we just passed through 12% completion. We’re steadily marching forward at rate of approximately one percent a month thanks to our contributors and welcome everyone to join in.

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)

2009/07/04

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

Filed under: project status @ 12:26 UTC

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

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)

« Newer PostsOlder Posts »