[RC5] client versions - AIX

waldo kitty wkitty42 at alltel.net
Wed Oct 2 10:24:53 EDT 2002

Jack Beglinger wrote:
> > As was noted earlier, it is typical for OGR workunits to take much
> > longer than RC5-64 workunits.  If you are using the most current
> > clients, there is no reason why you should not be able to process OGR
> > workunits until RC5-72 becomes available.  You are of course entitled
> > to ignore the OGR project if it isn't appealing to you.
> First off, a week is too long for any work unit.  

well, i guess we don't have to worry about you participating in any
distributed medical research studies, then... i'm in one where some
"units" have taken my machine 18 and 19 hours to complete... there are
10 "units" per block and one works on a block at a time... oh yeah, and
there's no checkpointing other than between "units"... so... 190 hours
or so... that works out to right at 8 days...

> It was also the most current
> version available.   OGR has no appeal to me - for this very reason.

why? the length of time it takes to process a unit?

i've left the rest of what you wrote below... it seems to be a decent
idea but it puts more on the perproxies than just proxy work.. it also
may not be possible for the perproxy to split a unit down for different
machines and then to recombine it before sending it off to the master
keyservers... if it was, wouldn't it have been done with the 64bit
stuff? i don't think that it can really be done due to the nature in
which the numbers are manipulated... when you shift or rotate numbers in
a register, you have to pull other bits in or push them out... if you
break a number into smaller parts and then try to rotate those smaller
parts, you don't get the same results because the bits being pulled in
or pushed out aren't the same... once you get past that very first
rotate and/or shift, you've already left the trail and can't get back to
it... it may be possible to do but the clients will have to talk amongst
themselves so that they can hand the other bits around to each other as
needed... at that point, we're into beowolf clusters and such...
> > While I'm mentioning long workunits, I'd like to point out to
> > everyone that RC5-72 workunits will be longer than RC5-64 workunits
> As I have mention prior too...  Give out bigger work units to personal proxies.
> Let them handout smaller usable ones (2^28 if required, maybe memory only
> clients or older machines) to the local machines.  Then the personal proxies
> can re-gather the information and hand back the big work unit to the server in
> sky. If a part is missing - it can locally rehand it out to get it fixed and the
> block big block returned.  This way, some of the large farms out there, you
> could hand out 2^48 or larger and let them do the sub work.  This way your
> server are off loaded.
> Also if the personal proxy runs out of work units... Allow it to pick the
> random block to use.  This way it will "create" a block and hand it out to the
> local crunchers.  In the end the personal proxy starts to appear to be the
> center of AMP machine, with one DNET client on each processor... no
> matter the type.
> At the same time let the personal proxies hand back pre processed stats.
> So checking a completed blocked from a personal proxy, also gives back
> tallies for the stats.
> --
> To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
> rc5-digest subscribers replace rc5 with rc5-digest

      (@@)                      Waldo Kitty, Waldo's Place USA
__ooO_( )_Ooo_____________________ telnet://bbs.wpusa.dynip.com
_|_____|_____|_____|_____|_____|_____ http://www.wpusa.dynip.com
____|_____|_____|_____|_____|_____|_____ ftp://ftp.wpusa.dynip.com
_|_Eat_SPAM_to_email_me!_YUM!__|_____|_____ wkitty42 (at) alltel.net
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