[RC5] Really useful feature request
pehu at im.se
Mon Apr 6 14:55:38 EDT 1998
Still no response from anyone calling themselves a member of the coding
team, maybe the usefulness hasn't sunk in yet... However I note four
responses agreeing that it would be useful, including one that is a
variation on the original idea (
http://lists.distributed.net/hypermail/rc5.Apr1998/0674.html ). No-one has
come up with a different idea that doesn't involving running scripts and/or
stopping the client. And the fact that these less-than-positive responses
were sent in at all, further strengthens the arguments for it - they
indicate that the problem needs to be solved.
Apart from wanting to make sure that this thread does not die out, I have
one slight modification to make, which will make it (idea #1) even better:
1:: When the client needs to do a fetch, and detects a buff-in.rc5 file in
its local fetch directory, instead of just _moving_ the new buff-in.rc5 file
to the working directory, it _fetches_ (LIFO) all the blocks it can use from
it, into its now empty buff-in.rc5 file. It would then be able to ignore any
partially completed blocks that it couldn't handle (from a different version
of the client, for example).
2:: If a client is running on-line and needs to do a fetch, it fetches the
blocks to its local fetch directory first, then uses them as in 1:: above
(keep reading before you answer this, there is a welcome side effect...).
3:: If the user performs a fetch, and the working buff-in.rc5 is _not_
empty, the client should just create a new buff-in.rc5 file in the local
fetch directory, but not fetch from it until its working buff-in.rc5 file is
empty, as described in 1:: above. The user can then move it out of that
directory, if desired, and mail it to the client that needs it.
The welcome side effect is this: The buffers would magically become FIFO,
without changing the main code of the program! The result is the following
list of benifits:
(!) No clients _ever_ have to stop running, giving maximum keyrate (except
for when you need to update the client version).
(!!) All blocks processed in the same order they come in (FIFO).
(!!!) No more messing with scripts to move buffer files about.
(!!!!) No more lost blocks, due to (occasional) problems with the
(!!!!!) Less hassle = fewer people dropping out of the effort.
OK, before responding with a negative answer to this proposal, read it again
- a couple of times - until you see what I'm getting at. Nobody has yet come
up with a relevant objection to my original idea (!).
Of course if my reasoning is flawed somewhere, then say so, but don't post a
respose containing the phrases: "...rename the file...", "...stop the
client..." or "...write a simple script...". If you do, you've missed the
point. Some of us have real jobs to do, and can't spend all our time
tinkering with Bovine maintenance, however much we may enjoy taking part in
it. As DG said in his response: "The sneaker-net is starting to get old."
Just to show you all how good it could be, my NT machine at work is running
the service version of the client (thanks to those that helped me set it
up). It has been running non-stop for 88:54:42.22, and has processed 974 RC5
blocks in that time - an average of 816418.14 keys/sec. It has 25 blocks
remaining in its buff-in.rc5 file.
In its local fetch directory is a 1000 block buff-in.rc5 file which I mailed
from home last night. At about 14:30 GMT, when this client generates its
first random block, I will manually move the new buff-in.rc5 file into the
working directory, overwriting the buff-in.rc5 file that will then be empty.
If my scheme were implemented, this would happen automatically, the buffer
would become FIFO, and I wouldn't risk processing a bunch or random blocks
if I happened to be in the bathroom at 14:30.
Oh, yes, and what about a bovine coder giving an opinion? What sayest thou,
oh mighty Nugget?
Send some money to distributed.net today. Visit EyeGive:
Just visiting does good and telling your friends makes it meaningful
"Microsoft: Bringing you ten-year old technology, tomorrow, maybe."
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5