[RC5] 2% down, 98% to go

Andrew Hime andrewhime at verizon.net
Wed Nov 23 01:44:35 EST 2011

On August 26th, 2010, distributed.net's RC5-72 effort reached 1% 
completion - an effort that took 2824 days, approximately 7.7 years. At 
the time, I did some quick math and predicted that we would reach 2% 
completion by February 4th, 2012.

We got there last night, November 21st. A workload that I figured to 
take 1.4 years took approximately 1.2.

It took 3276 days to do 1% of the RC5-72 keyspace - a time of almost 9 
years. At the current keyrate, we will complete 100% of the keyspace in 
136.5 years. At the current keyrate, we will reach 3% completion in 
approximately 1.4 years, or around April 10th, 2013.

I did some rough math (back of napkin kind of stuff). Assuming that the 
keyrate doubles approximately every 18 months (which, ignoring the 
introduction of the Stream client, still seems valid), we will reach 
100% completion within 9.3 years.

So, somewhere between 9 and 137 years to go. Given the lag time after 
OGR-27 completes (somewhere between 1.5-4.5 years from now) and before 
the next OGR project starts, those numbers are likely on the high side.


I've maintained the formatting from my previous post on this subject, 
now some commentary:

About the Stream clents - Windows Stream has been the #1 client for 
quite a while now. A few months back, they accounted for more than half 
the total workload ever done. A few days ago, they accounted for double 
the workload of the #2 platform - Windows x86.

There are now 64-bit cores available for RC5. While they are not as 
marked an improvement in speed as OGR, one no longer has to choose 
projects based on "bitness", and they do provide a small speed increase 
over 32-bit. When people argue against doing a 64-bit version of a 
program, I enjoy having something to point to that shows there are 
benefits other than memory addressing (not to mention SSE2 and the like).

The growing prevalence of real GPUs (not Intel's solution) and of 
multicore computing has made solving these problems very viable. Just by 
way of example, my work computer (yay working!) was recently upgraded 
from some horrible Pentium D/Pentium 4 thing to a Core i5 running at 3.3 
Ghz. With 4 cores, it processes OGR at approximately 230 Mnodes/s - a 
score not much lower than my Core i7-920 (2.6 Ghz) at home. And the i5 
is only running 32 bit Windows XP. So things are definitely looking up.

Goals we should probably start working on now:

Short term:
upgrading 32-bit clients to 64-bit - with the increased speeds and the 
fact that most every shipping computer is running 64-bit OS, I'm 
surprised that the 64-bit clients are not gaining on 32-bit faster

Long term:
Given the institutional slowness d.net is well-known for, we should 
probably start talking NOW about what projects will come after RC5-72 
and OGR-27... and also start work on a v3 client, which appears to have 
long ago been abandoned. The primary feature I'd be looking for is 
better granularity of stats (another abandoned project). Given the 
prevalence of broadband and the low overhead cost, the data being 
shipped back to d.net should probably be reporting back more 
information, like client configuration (ie processor type and speed and 
such). I had a laptop stolen a few years back and inquired about dnetc 
phoning home. I received a response that an old client had phoned home. 
When I inquired further, I was met with stony silence, which is par for 
the course. (Of course, these features could be made opt-in or opt-out 
with a warning on initial configuration.) Another feature that is sorely 
needed: buffer file combination/flexibility. I have to fetch/flush by 
mail at work, and having to juggle these files is really nonsensical, 
among other things.

See you at 3%!


Old predictions:

Approximate completion of OGR-27: 2014-2018
Approximate completion of RC5-72: 2021-2152

Current predictions:

OGR-27: 2013-2016
RC5-72: 2020-2148

More information about the rc5 mailing list