[RC5] Really useful feature request

gindrup at okway.okstate.edu gindrup at okway.okstate.edu
Tue Apr 7 11:14:21 EDT 1998

     You don't have to stop the client to do what I suggested, it's just 
     prudent.  Of course, I assumed that you were using checkpointing 
     files, if you aren't then my solution won't help you.  All my 
     solution comes down to is noting that there are two ports into which 
     the client reads buff-in files.
     It is always prudent to stop the client when shuffling files.
     A coding solution for this strikes me as a step in the direction of 
     feeping creaturism.  The problem is not hard to solve using tools 
     already available (around the house).
     An elegant solution for this problem on *ix machines would be to 
     replace the buff-in with a FIFO that (sequentially) multiplexes 
     however many buff-in files you chose to have.  Have it share a 
     memory segment (indicating file boundaries) with a FIFO at the 
     buff-out and you could have the buff-outs match the buff-ins.
     This doesn't do much for non-*ix machines (except possibly OS/2, 
     BeOS, AmigaOS, and MacOS).  So the MS OSes don't have this elegant 
     solution available to them.
     Still, since the client already sequentially multiplexes from the 
     checkpoint and buff-in files, I don't see that there's a problem.  
     It also seems to be robust under the sudden removal of the buff-out.
            -- Eric Gindrup ! gindrup at okway.okstate.edu

______________________________ Reply Separator _________________________________
Subject: Re: [RC5] Really useful feature request 
Author:  <rc5 at llamas.net> at SMTP
Date:    4/6/98 1:55 PM

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: 
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

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