[RC5] Really useful feature request

Jim C. Nasby nasby at enteract.com
Mon Apr 6 22:07:45 EDT 1998

I will agree whole-heartedly that your idea is a good one, but we don't have the
resources to impliment it right now, especially since there is a work-around.
Although it might look like we have a small army of coders, most of them only do
porting and hand-tuning of the cores. There is other stuff that is being worked
on right now (mostly expanding our platform support and bug-fixes), and new
features are not currently a priority.

We do value user input and we do take note of it, even if we don't 'officially
respond'. We have taken note of your request and will keep it in mind.

D.Net User Interface

Peter Hugosson-Miller wrote:

> Hi there!
> 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
> aforementioned scripts.
> (!!!!!) 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?
> --
> Best regards,
> Peter Hugosson-Miller
> Send some money to distributed.net today. Visit EyeGive:
> http://www.eyegive.com/html/ssi.cfm?CID=1098&email=hugge@bigfoot.com
> 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

Jim C. Nasby (aka Decibel!)                                  /^\
nasbjim at charlie.cns.iit.edu                                 /___\
Freelance lighting designer and database developer         /  |  \
Member: Triangle Fraternity, Sports Car Club of America   /___|___\

Give your computer some brain-candy! http://www.distributed.net Team #1828

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