[RC5] 2% down, 98% to go
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:
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
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%!
Approximate completion of OGR-27: 2014-2018
Approximate completion of RC5-72: 2021-2152
More information about the rc5