[RC5] DES-Test, Day 2

Marc Sissom marcus at teleteam.net
Sun Jan 10 21:12:20 EST 1999

William E. Powers wrote:
> > My Intel Celeron 466 (overclocked) machine is about 500-600 times faster
> > than 386SX-16, let it be 400 times faster than your 386-25 test machines.
> > The total number of machines involved is something like 200,000. Even if
> > there were 40,000 386s involved, they could have been replaced just by 100
> > Pentium II-450s or 50 Dual PII-450s.
> >
> > If all the other (160,000) machines were at least 100 times more powerful,
> > the contribution of 386s would be
> >
> >       (40,000*1) / (160,000*100+40,000*1) * 100% = 0.249%
> >
> > Would it help the project a lot?
> If the 386 is taking up, say a network drop, while a PII sits idle
> nearby, then it's hurting.  Yeah, right!
> Otherwise, even if it only does one block a day, it's helping,
> because that block wouldn't get done if the 386 was turned off.

Actually, if the project is only expected to last one day, or less,
the 386 is hurting not helping since that block would be tested by
another machined and the recycling is only adding to the load on
the keyservers which is taking their cycles away from cracking.

Has anyone looked into some open source network and disk i/o code
to see how much it actually costs in keys or cycles to receive/buffer/
store/retrieve/buffer/send a keyblock?

> Is it significant?  Let's say there's 10,000 386's cracking one block
> a day.  That's 10,000 blocks a day, 3,650,000 a year, that would
> be cracked later than necessary, and only because we insulted
> their owners by dismissing their contribution.

Only if the project lasts long enough for the 386s to turn over
blocks. Earlier(in a post that apparantly got moderated) I defined
"small" projects as any project where 50% of the work would be
dispersed to the clients in 50% of the amount of time that it takes
any particular client to process the smallest unit of work. Basically,
if your box takes 12 hours to complete one work unit, and half of the
work is dispatched in 6 hours, your box might, or might not end up
being a contributor to the project as a whole.

It seems strange, but the slow boxes would be most valuable on long
term projects. Any project that approaches "real time" should be
reserved for the faster boxes. Recall(from the archives) our
discussions on making a real time chess engine. If a box takes too
long to analyze a set of moves, it is worthless. If it does not
have a real-time-online connection for the duration of the match,
it is worthless.

I had not considered this before, but we had never measured any
project in hours before. Previously, all projects lasted days or
weeks and any cpu was valuable. It looks now that d.net has grown
and sped up enough so that even projects that used to be long ones
are approaching those real time limits that we discussed so long
ago. Everyone, reserve those slower boxes for the projects that are
still long term efforts.

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