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.
Behind the scenes, we are getting ready to move over to our newest project: OGR-28. This is to discover the most optimal Golomb Ruler with 28 marks. We anticipate that it will take about as long as OGR-27 has. It has some features in common with OGR-27: some of the packets will be very large (up to 1500 Gnodes), and there are three stub spaces. We expect that the first two stub spaces will take about 90 days to complete. Ask me about that last part in a few months time. :)
For the stats freaks among you, the number of stubs for each stubspace of OGR-28 is below:
Stubspace 1: 115676
Stubspace 2: 5823649
Stubspace 3: 518152118
It won’t be necessary for you to upgrade your client software, since OGR-27 clients are ready for OGR-28. If possible, though, I would recommend that you do have the most recent version. If you are running Windows 7 or 8 and your computer is less than four years old, that’s this one: http://http.distributed.net/pub/dcti/current-client/dnetc-win64-amd64.zip :)
If you are running something else, have a look on our download page: http://www.distributed.net/Download_clients
Once again, we will be sending some distributed.net swag to the lucky users who found the Optimal Golomb Ruler this time!
We have completed over 96% of the work and are now close to wrapping up OGR-27. Some of you may have noticed some difficulty getting OGR packets earlier today, due to our need to begin recycling of the remaining stubs. As I write this, there are about 20 million left that need working on. It is likely that you may experience difficulty occasionally in the coming weeks when hoping to collect OGR stubs to process. This is due to the master key server being unable to speak and chew at the same time!
If you have a long memory, you may remember a note from me about needing to complete one more verification pass on a small number of stubs, about 2.2% of the total, that had been processed by buggy client versions. Now is the time! Some of you are already working on these stubs. One of our core contributors “Stream” has calculated that it will take us about 3 weeks at our current average (400 Gnode/sec) to complete the verification of the earlier stub spaces.
Today we also mark the 4000th day that we have been working on the RC5-72 project. We passed 3% completion only a few weeks ago and continue to make steady progress.
As ever, you can catch up with us in #distributed on IRC (irc.distributed.net).
Do you have an Android device on your desk languishing on charge while
you are asleep? Perhaps you have a shiny new tablet? It is now
possible to run OGR on it! Late to the dance, I know…
It is running using the BOINC Wrapper technology. You can download the
BOINC app from Google Play or the ‘Market’ app (depending on your OS
version.) Just attach it to the yoyo@home project:
http://www.rechenkraft.net/yoyo/ and follow the instructions.
It has been a while since I have posted any updates to my blog here. I’ve even had a few notes asking if we’re still working on our projects. I can assure you that we are.
We’re going full speed ahead on OGR. My favourite web page at the moment is http://stats.distributed.net/project/ogr_status.php?project_id=27 , which shows in detail how many stubs we have left to process until OGR-27 is complete.
At the same time, we’re still working on RC5-72; where we have nearly completed 3% of the total work space. We released new client software over the summer which works around the incompatibility we had with AMD 7xxx series graphics cards. The keyrate history graphs for RC5-72 and OGR (http://stats.distributed.net/keyrate.php?project_id=27 and http://stats.distributed.net/keyrate.php?project_id=8) are back online after a hardware failure.
I hope to have some more updates for you very soon. :)
After three years of effort, we have passed the half-way stage of this ground-breaking project. We thank you for your continued participation.
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.
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!
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.
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 220.127.116.1175, 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.
We’ve just transferred some new clients from the pre-release page to the
official release page: Download Clients
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]