[RC5] DES-Test, Day 2
marcus at teleteam.net
Mon Jan 11 19:06:03 EST 1999
rc5 at xfiles.nildram.co.uk wrote:
> On Sun, 10 Jan 1999, Marc Sissom wrote:
> > William E. Powers wrote:
> > >
> > > 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.
Speaking of grasping at straws! The fact of the matter is, if
you pull a keyblock from the server and don't return it before
the contest is over, you are hurting the effort. The reason
why the block does not come back is irrelevant. You can deny
it all you want, but you can't change the measurable, observable,
> 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.
Yes, there is a chance that they could help. There is also a
chance that they would hurt. It does not matter whether you
say so or not. The one fact that we have is that handling
clients costs cycles. If the key is taken and not returned,
the box that took it hurt the effort. Period.
> DES is not real time... Perhaps we should allow a smaller block
> size for DES - then everyone could contribute.
Re-read the definition of real-time for this context. If it is
likely that a box would not be able to return keyblocks before
the contest is over, then it should refrain from that particular
project. DES is now "small" enough, and the general population
of d.net has grown large and fast enough where things like raw
single processor speed are going to start to make a difference.
This is not a new concept, it just has not happened, yet. The
point is, it will.
Many people have spent many hours hand optimising the clients
in order to get the absolute maximum possible performance from
each architecture and each implementation. Now we are coming
upon an opportunity to optimize the network.
> > 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?
Certainly, the reason for not returning the blocks is irrelevant.
When the EFF cracker joins in on the real DES, we will see about
a 2x increase in the total keyrate. That means that the project
will take half as long as the test, or even less. The test took
about four days. Expect the real thing to take two or three at
most. If you have a box that can turn over a block in 24 hours,
by all means, bring it on. Just be aware that in the future, that
box might not be a benefit to the cause.
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5