Lack of communication, was: Re: [RC5] Supspace 0x68

gindrup at okway.okstate.edu gindrup at okway.okstate.edu
Tue Jun 9 16:34:45 EDT 1998


     I tend to agree that this "shot" was a little stronger that I felt 
     about the issue.
     
     And this is the sort of thing that "medium involved" people need to 
     know -- people like me who run *a lot* of off-line MS-DOS machines 
     because networking these MCA PS/2s would cost too much.  People in 
     the "large off-line" camp *have* to know when the subspace their 
     off-line pools are working on are being reissued so they can flush 
     buffers and not completely waste the effort they've put into 
     sneaker-netting the blocks to each member of the off-line farm.
     
     Sure, I'm no McNett in the contribution department, but I also don't 
     just blindly run the client.  Running the client on the machines I 
     run requires *actual effort* to manage and nontrivial time 
     requirements to:
        1) find out when blocks in the buff*s of the off-line machines 
     are about to be reissued so that the buffers can be flushed and the 
     machines can be idled
        2) find out when a new block is about to be opened to fetch 
     buffers and un-idle the off-line farm.
     
     The trouble is, using your analogy, I'm putting in a lot of effort 
     to feed cows that aren't on the D.Net range.  That this effort is 
     instantly wasted if the grass I'm carrying is fed to another cow is 
     somewhat of a let-down.
     
     Very little effort on the part of an "organizer" could ensure that 
     the amount of wasted or duplicated effort was reduced both for me 
     and for the effort.  Reissuing a block ties up bandwidth twice 
     (irrelevent) and ties up two CPUs on the same work (relevent).  The 
     point, from a ceratin point of view, is to wring as many keys per 
     second as possible out of the D.Net computer (else, why all the 
     effort to optimize the clients and get improved cores distribted as 
     quickly as possible?).  Invalidating the work of the off-line herds 
     due to the lack of a trivial communication is not exactly concordant 
     with that point.
            -- Eric Gindrup ! gindrup at okway.okstate.edu


______________________________ Reply Separator _________________________________
Subject: Re: Lack of communication, was: Re: [RC5] Supspace 0x68 
Author:  <rc5 at llamas.net> at SMTP
Date:    6/8/98 7:14 PM


     
     
Richard Ellis wrote:
     
> And once again we seem to have encountered the same old problem with d.net. 
> A severe lack of communication between the high elite and those of us in the 
> trenches.
     
Oh, Please.  Let's not make this more of an issue than it needs to be.  I know 
that people like Jim don't consider themselves the "high elite".  Neither do 
some of us consider ourselves "in the trenches".  More accurately, the main 
difference between folks here is the level of involvement.  If you don't like 
the way things are going, volunteer your services and try to improve things.
     
<snip>
     
> This is the kind of information that we want (and need) to know,
     
Speak for yourself.  I really don't care too much about this.  I'm donating raw 
processing power towards the effort, and the more active folks are in charge of 
managing it.  If they do something bone-headed in management that wastes 
processing time, it's their problem and I'm sure they'll figure it out.  If 
nothing else, any mistakes will teach us all something about distributed 
processing management.   (This is an experiment, remember?)
     
<snip>
     
> And please don't use the same old tired excuse of "we are volunteers
> spending our free time on this project and there's not enough of that to go 
> around."
     
That's a perfectly valid response.  They are volunteers who are more deeply 
involved than most of us.
     
> I have news for you, those of us in the trenches are also
> "volunteers" and we are also "spending our free time on this project" and we 
> too generally do "not [have] enough of that to go around,"
     
True, but our level of involvement is much, much lower.  There's a big 
difference between those who just run the cracking programs and those trying to 
actively manage the process.
     
> yet somehow we
> continue to find the time to run the clients and find new machinery to bring 
> into the project.
     
Yes, but that effort is fairly trivial compared to the efforts of some of these 
people.  Unless you're spending many of your hours a week towards the effort 
(yours, not your machine's) then you aren't contributing on their level.
     
>  It takes all of about 30 seconds to type out an email to
> the announce list with that single line above after the decision is made to 
> reissue a subspace.
     
Big deal.  The message would have meant little to me and probably at least 95% 
of the participants.  I would have tossed it without reading it.
     
> Therefore the extra time for a little communication
> between the elite and us in the trenches shouldn't keep anyone away from
> anything.  And that 30 seconds spent would create far more good will towards 
> the project than the ill will created when we find out after the fact that a 
> switch occured but we were not told about it.
     
Communication is always good, but this particular issue is no reason to get your
undies in a bunch.
     
Let those more involved manage the process.  Be a sheep (err...cow?) like me and
just crack blindly.  If you want to be part of the management process, then get 
involved and quityerbitchen.
     
I'm udderly proud to be a small cow on this big farm.
     
GDN
--
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