Re: 2% down, 98% to go

That was a great writeup, Andrew!   In your section about things we 
should be looking at, I would vote for a hybrid client that would be 
able to use CPU, Cuda and/or Stream all in one client.

I am sure there are fair number of people that are running DNETC, and 
don't even realize that they have a video card that can do it too.


On 11/23/2011 12:44 AM, Andrew Hime wrote:
> 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
> _______________________________________________
> rc5 mailing list
> rc5-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
> http://lists.distributed.net/mailman/listinfo/rc5
>

_______________________________________________
rc5 mailing list
rc5-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/rc5