[RC5] Suggestion

Steve Bennett me at stevage.com
Tue Dec 17 18:27:32 EST 2002

It was pointed out that the second issue will go away with the new batch of
clients, which specify some new format of buffer which is less apt to
change.  Is that going to fix the first problem though?  It seemed the
problem was that different cores attack the block in different orders, and
thus you can't switch cores, etc etc.  In that case, shouldn't the client be
modified to not allow core switches mid-block?  Again, it seems pretty silly
that the client can detect what core the current block was started with, can
choose a core - and yet chooses a *different* core, and then deletes the
block!  I can't imagine the difference in core speeds is ever enough to
justify deleting a half-finished block and starting over with a different


-----Original Message-----
From: owner-rc5 at lists.distributed.net
[mailto:owner-rc5 at lists.distributed.net]On Behalf Of Greg Wooledge
Sent: Tuesday, 17th December 2002 11:09 AM
To: rc5 at lists.distributed.net
Subject: Re: [RC5] Suggestion

First, there is the issue Michael is talking about, in which a client
that's restarted may DISCARD the work it has done on a block, simply
because the phase of the moon causes a different core to be selected
by the mini-benchmark that it runs.

Second, there is the one-time issue in which users upgrading from
RC5-64 clients to RC5-72 clients must MANUALLY delete their old
buff-* files in order to avoid ALL WORK BEING DISCARDED every time
the shiny new client is stumped by the presence of an old-format
buff-* file, and simply throws the work to /dev/null rather than
do something intelligent with it (like writing it to a different file).

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