[RC5] Dupes and other client issues

Mike Spann mikes at gammalink.com
Wed Apr 22 10:25:27 EDT 1998

> Date: Wed, 15 Apr 1998 17:51:40 -0400 (EDT)
> From: "Peter A. DeNitto" <denitto at llamas.net>
> Subject: Re: [RC5] Dupes 

Lots of good stuff that I agree with cut..
> Version #       Dupes   %of Dupes	Blocks	%Tot	%Dupe
> ...
> 7006            24444   3%		283040	6%	9%
> 7005            1193    0%		30315	1%	4%
> 7004            71      0%		4411	0%	2%
> 7003            909     0%		3564	0%	26%
> 7002            295007  37%		63399	1%	465%
> 7001            19991   2%		197923	4%	10%
> 6404            22238   2%		245918	5%	9%
> 6403            58248   7%		309090	7%	19%
> 6402            21384   2%		220332	5%	10%
> 6401            65772   8%		497926	11%	13%
> 		-----	---		------  ---
> 		509257  64%		1855918 39%

Lots more good stuff cut.
> Conversely:
> New Clients account for 61% of all blocks submitted.  With dupes it is
> 57%.  The chance a new client is doing a dupe block is 9%.

Now for what I don't necessarily agree with

> Upgrade your clients.  This shouldn't be a "Well, these stats don't mean
> anything to me, so I'm not going to do anything" type of deal.  This is a
> "I need to have a working correct client whose core works, buffers are
> more stable, and the client reports back valid data."

You show that the chances of my client making a dup with whatever you call
a 'new client' is 9%

You show that the chance of my client making a dupe with my 6401 client
(the most productive client out there by your stats) is 13%.  I don't know
about the rest of you, but I will take those odds to keep a known reliable
client running and avoid the grief I have to go through every time I
upgrade to a new and unproven client.  The 'latest and greatest' client we
were all running when DES-II finished did not run RC5 on many machines. 
That is a fact.  6401 was out and stable.  There was a flury of various
clients that also did not run on many machines.  How do we know which
version is now stable for our machines? 

Now, if you were to post detailed stats on what you consider 'new clients'
along with a list of bug reports against them, we could make 'informed'
decisions whether to upgrade and how far.  Otherwise, many of us are going
to stay with the devil we know.  To claim that 'the latest client is
always the best and most stable' when everyone knows this is rarely true
does very little to improve your credibility.  I am sure 7002 was the
'best and most stable' when it was released, as was 7003 and ...
Regretably, while this list will often inform people which versions are
bad clients, it rarely informs people which versions are good.

On another topic.  We all know that stats are based on 28 bit sub-blocks. 
Most of us also know that some of the clients will check 4 28 bit
sub-blocks faster than they can a single 30 bit sub-block.  Many of us
only run 28 bit sub-blocks for this reason. 

Are there any stats on the what you consider a 'new client' to indicate
whether this is still true with 'new clients'?  I personally do not have
time to run a dozen blocks through each version of the client for each
block size to measure the throughput at different block sizes.  I wonder
if someone else is bored enough to run those tests.

If newer clients, unlike the old ones, do get performance improvements
from running larger blocks, have the proxies and pproxies been given any
notion of a 'buddy system allocator' (or any other suitable algorithm) to
allow them to give out preferred size blocks when possible?  To me, it is
silly to give out a 3x2^28 block when right behind it is a 4x2^28 like the
client asked for.  That 3x2^28 should only be given out to a client asking
for a 4x2^28 when it is the last block the proxy (or pproxy) has (or
possibly is getting stale), otherwise should be saved for a client that
wants a 3x2^28 or smaller. Yes, I know that a buddy system allocator would
never make a 3x2^28 :)  A 2^30 block would be split into two 2^29 blocks
and one of them split into two 2^28 blocks.  The free list would have
howevermany 2^30's left, one 2^29 and one 2^28.

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