[RC5] keys stuck in a loop??
wkitty42 at alltel.net
Fri Sep 14 13:14:24 EDT 2001
Bruce Wilson wrote:
> Maybe not a problem. Notice that the one it actually works on is a
> lower key number than the one it hasn't done yet. The client uses a
> pseudo-FIFO, based solely on the key number. If this really bothers
> you, just let it run dry to finish off that one key, then -update to get
> new work, but it's not doing any harm.
ahhh... i hadn't noted that particular aspect... it is only on the linux
boxen that i see this... at least at this point... they were the ones
that jumped out at me... the boxen available are OS/2, linux, and
win9x... all are configured exactly the same... two keys in, one key out
> For what it's worth, the processor you're showing should really be
> working on larger work units, and should be caching a few. A reasonable
> target is for each client machine to connect once or twice per 24 hour
> period, and to have enough work cached to keep working for 24 hours. If
> this machine was unable to reach the fullproxy network (your fault, our
> fault, someone in between) it would work on randoms, which have a high
> probability of being duplicate work, which is wasteful.
i'm running a perproxy here servicing a dozen machines on the internal
network and possibly a few from outside... the reason i have them
configured in such a "short stack" is that i highly dislike waiting
hours or days to find out that something is wrong... that's also why i
dumped OGR processing... these machines range from 486-33 to celeron 300
with at least one amd k6-450 in the bunch...
also, i very much disliked going to the stats pages and seeing the
entries "bouncing around" as keys were dumped in in large bulks every
other day or so... with the current configuration, the graph is very
smooth instead of hugely spikey and i also get a better idea of my daily
average unit processing without having to do any math...
> Connecting every 20 minutes is wasteful in other ways, too. By
> connecting 72 times a day, you are putting an unnecessary load on our
> network, and reducing your effective keyrate.
that's why i have them configured to have at least one key in the buffer
at all times... one waiting, one being processed... the background
threads should take care of sending completed and receiving new units
while the client handled that second key that was waiting...
(@@) Waldo Kitty, Waldo's Place USA
__ooO_( )_Ooo_____________________ telnet://bbs.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