[RC5] LIFO? Is this true?

Marc Sissom msissom at dnaent.com
Tue May 12 11:31:19 EDT 1998


Jim C. Nasby wrote:
> 
> Marc Sissom wrote:<snip>
> 
> > Nah, people in general just have too much interest in dupes, stale
> > blocks, randoms and bla bla bla. Most of which has no real influence
> > on the outcome rc5-64 project. Nothing against thinking mind you,
> > I just think that there are a lot of other things that I'd rather
> > think about ;-)
> 
> Marc-I hope you were kidding here...

If you read the entire message, including the previous paragraph
and the smiley, then the question is pretty clearly answered. I'm
serious. I don't give a flip about dupes that I produce because
I don't produce very many.

> dupes are a serious issue and will
> effect the timeframe of RC5-64, even if it doesn't affect the eventual
> outcome. The last time Daa posted stats on our dupe rate, I believe that
> something like 40% of the blocks returned were dupes, mostly from old 2.64
> clients.

Yeah, I still haven't figured that one out. Why would old
clients preferentially be producing dupes?

> As has been mentioned in the past, dupe rate and block latency are very
> important in timed contests such as DES-II.

As I have mentioned, I'll turn off my other distributed projects
off when des2-2 comes around, even if the most recent client
available is dated from February. I have not asked you, so here
I will:

	Do you need a coder for linux alpha???

> So, once again, please do not buffer any more blocks than you need to. 

Don't worry, I run through a pproxy here, as I outlined in
the previous message. I am not a serious duper and I don't
give a flip about how old the blocks are in the client's
buffers because our network and hardware are reliable. As
such the blocks in the in-buffs should be old because they
never get touched.

>We are
> doing our best not to re-issue blocks that are less than ~2 months old, but
> there really shouldn't be any blocks hanging around that long if it's
> avoidable.

If our net goes down for a day, the blocks will be consumed and
then the clients will produce randoms. So for a few hours our
network might be producing dupes. Then it's back on line and
all get a fresh set of in-buffs. It's just not worth it Jim, to
walk around and intrude on everyone's office, lab, or whatever
and purge the buffers. This stuff is not supposed to be a con-
sumer of real resources.

I don't know how others feel about this. I imagine that there
are a wide variety of opinions, but I've tried to volunteer
for this project many times and gotten nothing but rebuffs if
I've gotten any response at all. Oh, how I long for the days
of v1 when I was building autodialing clients for os2 and linux
with cores produced by Remi G.

Sorry, if all d.n wants is my cpu idle time, that's all it's
going to get. If it costs a few hours of dupes and randoms
every three months or so, too bad. That's d.n's choice to make.

The reason that other distributed projects have higher priority
is because I can do more for them than just pay an electric bill.

Seeya when v3 arrives.

--
Marc Sissom                       http://www.dnaent.com
Design Engineer                     voice: 972/644-3301
DNA Enterprises, Inc.                 fax: 972/644-6338
--
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