[RC5] CSC - RC5-64 Comparison and Moo Payback Calculations

Zorba the Hutt zorbathut at uswest.net
Thu Dec 2 03:00:51 EST 1999

Heh, just noticed something vaguely entertaining . . . as of the next stats
update, I predict that our CSC completion will pass our RC5-64 completion,
despite the (relatively) glacial keycrack rate of the clients. Sure
demonstrates the difference eight bits makes, doesn't it? Two month ETA to
end of keyspace at current rate, meaning a 50% completion probability in one
month. Personally, I'm betting it'll be over before that, just because
people might still be switching over to the CSC client, although without the
moo, we might have as many converts as we're going to get.

Which leads me to my next comment - an argument for adding Pretty Statistics
and a Moo back to the Win32 GUI clients. To convince people, I have pulled a
large amount of statistics out of thin air, because I haven't got a clue
what the real numbers are. I hope this convinces someone :)

First: We are currently cracking RC5 (as of however often the main page gets
updated) at 83.79GKeys/sec. Pre-CSC it was higher - I'm gonna call it
90GKeys/sec. Let's assume that 50% of this is due to Windows users, making
45GKeys/sec. (Incidentally, I will cheerfully revise these calculations if
anyone can pull out better statistics for me). OK, now of this 45GKeys/sec,
let's assume that our Win32 GUI Team has added a Glitzy Crack Mode (GCM). It
has a screensaver setting with lots of pretty flying colors and meaningless
indicators, but it looks good, and that's what matters. First: half our
users are going to turn the GCM off (22.5GKeys/sec). However, the addition
of the GCM makes the client run . . . ONE PERCENT slower. (Incidentally, one
percent slower is absurd, our coders are better than that. This is "for
argument's sake".) So our Non-Glitzy Users are going to have a combined
keyrate of 22.275GKeys/sec. Now, our other half of the users are going to
leave it on, and let's assume that the GCM uses 10% of the CPU when it's
actually being pretty (I think this is pretty high also, depending on
complexity I'd guess 1% to 5%. Consider that these are probably not going to
be high-quality 3d renderings, this is more likely to be text and sprites).
So anyway, our Glitzy Users are going to give us a combined rate of
20.25GKeys/sec. Add these together, and we have 42.525GKeys/sec. Add this
back to the half of the keys that aren't coming from Windows users, and we
get 87.525GKeys/sec. Now, 2.5GKeys/sec (roughly) is not that big of a
sacrifice. Taking a look at the stats, we see that there are about 15
thousand users that contributed blocks to RC5 yesterday, and 15 thousand
users that contributed blocks to CSC yesterday. Now I'm going to pull even
more numbers out of my hat and simply add them together. (Consider: a user
might submit a block to rc5 and csc, especially if they're maintaining lots
of systems that can't be updated easily. Consider: a user might have more
than one day's of blocks buffered, and therefore not have contributed
anything yesterday. Perhaps we need an "active users in the past week"
stat?) So we get 30,000 active users at dnet total. Call it half of those
are Windows users - 15000. Say we could attract 5% more users by adding a
glitzy interface. 22.275GKeys/sec / 7500 users (assuming that half the users
are glitzy) = 0.00297GKeys/sec/user. 0.00297GKeys/sec/user * 750 new users
(do the math yourself on that one) is 2.2275GKeys/sec. Making our New
Revised Keyrate . . . 89.7525GKeys/sec.

OK, so we've lost a quarter of a gigakey per second. But considering that
these are total ballpark answers anyway, I don't think it's too bad, and if
we cut out the 1% penalty for adding the option to the clients (which I
still think would never happen - we're talking one percent of a percent,
MAYBE) then we make a profit. And I'm almost certainly screwing up on the
actual numbers here, but, hey. Someone give me better stats so I can


To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list