[RC5] DES-Test, Day 2

rc5 at xfiles.nildram.co.uk rc5 at xfiles.nildram.co.uk
Mon Jan 11 17:24:18 EST 1999


On Sun, 10 Jan 1999, Marc Sissom wrote:
> William E. Powers wrote:
> > 

[ snip ]

> > 
> > 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.

Wrong:  The 386 will never hurt.  If - and only if - it is unable
	to return ONE block, it will not help - however, it won't
	hurt.  There is a chance it may get THE block, and stop
	a P2 cracking it, then again, there is a chance it could
	be lost by A P2-450 which burns up cause someone over
	clocked it too much :)

> 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?

As for the proxy's load being increased and reducing its keyrate,
you're grasping at straws.  Apart from the fact it takes less than
a second of total processing time (so thats, say 1 million keys max),
the 386 would be able to contribute more than that.
 
> > 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.

There is a chance it would help.  They would not hurt - the key would
just be re-issued, and the 386 would be wasting its time, but no
more so than if it wasnt't helping.
 
> 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.

DES is not real time... Perhaps we should allow a smaller block
size for DES - then everyone could contribute.
 
> 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.

An online 386 would probably contribute more than many P2s run
by dial up users who only connect daily - should they stay on
long term  efforts too?

David Taylor
E-Mail:	dtaylor at nildram.co.uk.spam
ICQ:	268004
[Remove .spam from e-mail to reply]



--
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