greg at wooledge.org
Mon Dec 16 19:08:33 EST 2002
Mark Duell (mduell52 at cox.net) wrote:
> ----- Original Message -----
> From: "Michael Shannon" <MichaelS at towersoft.com.au>
> > - a slow machine is cracking a key
> > - it spends a long time (many hours or even days) getting to a certain
> > point (say 80% done)
> > - the machine crashes, the client is restarted, etc.
> > - when the client is fired up again, it chooses a different core and
> > starts the same key from the start
> 1) New client versions don't arrive daily.
> 2) Couldn't you use the checkpoint file feature to solve the the problem you
The two of you are talking about two separate problems that dnet users
have faced over the last few weeks.
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).
Checkpoints, which are wonderful, do not help with either of these
Greg Wooledge | "Truth belongs to everybody."
greg at wooledge.org | - The Red Hot Chili Peppers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.distributed.net/pipermail/rc5/attachments/20021216/8776f82a/attachment-0001.bin
More information about the rc5