[plans] distributed.net .plan update
plans at nodezero.distributed.net
plans at nodezero.distributed.net
Fri Jan 7 19:00:01 EST 2000
.plan updates in the last 24 hours:
decibel :: 07-Jan-2000 05:06 (Friday) ::
The CSC statsrun isn't co-operating again. I'm trying to fix it,
but I'm getting 80% packet loss to statsbox. More as the situation
decibel :: 07-Jan-2000 05:19 (Friday) ::
Ok, I finally got back into tally. I'm running the csc em_rank update
right now. In the interest of time, I'm going to shut off http so that
I'm not competing with all of you for CPU time. I promise I'll turn it
back on as soon as possible!! }:8)
vetere :: 07-Jan-2000 06:21 (Friday) ::
-452 is being operated on as I write this; I have binaries on my hard
disk and am banging on them. I'll detail some bugfixes below, as well as
new developments in the add-on world.
Here's something cool:
There's a freeware screensaver available called MacDim, at
http://www.ibrium.se/macdim.html . It launches small modules - basically
applications that are opened via AppleEvents, display their graphics,
and close via another AppleEvent.
We can turn dnetc for the Mac into a MacDim module. :)
Top hackers are planning to work on this, but things like
multiprocessing and bugfixing have higher priority. You're welcome to
help out. The possibilites are endless - the dimmer could be combined
with the Java log visualizer, an FBA eventually... and the Start&Hide
AppleScript should come in handy.
Let's put that Windows screensaver to shame! :)
In other news...
Michael Feiri appears to have fixed the reconnect failure bug. "I
switched lowlevel connectivity inside GUSI to MacTCP because in the
OpenTransport variant there seems to be severe connection maintainance
bug that causes the client to lose [its] connection to the outside
world... The result for the endusers is that network IO is now much
slower but on the other hand it seems that the client can now correctly
redial to the internet" when there has previously been a connection.
- DriversLib no longer needed
- OpenTransportLib ditto
- 68k synced with PowerPC code
- 68k client uses old assembly RC5 code; faster
- modified buffer IO code in an attempt to fix buffer exchange bugs
Coo coo ca choo.
decibel :: 07-Jan-2000 07:18 (Friday) ::
Ok, everything on CSC should be all set again, hopefully just
in time for us to announce that it's over tomorrow };8)
(NO, this does NOT mean we found the key yet!) }:8)
dbaker :: 07-Jan-2000 09:47 (Friday) ::
I've gotten a very large number of emails asking for clarification
on the distributed.net reissuing policy and for details about
the precise amount of blocks being reissued. I have been distributing
this form letter:
Thanks for your email regarding my post or about CSC being shown
as more than 100% complete on the statistics page.
It is perhaps a common misconception that each CSC work unit
completed is unique. With a short contest like CSC, we have
implemented special keymaster code to use complex tests to verify
the authenticity and validity of each work unit submitted. Malicious
users could conceivably run a tampered version of the distributed.net
client to gain an unfair advantage in statistics and rankings. In
order to test an experimental method of attempting to uncover and
disqualify these users, it was decided that certain CSC work units
would periodically reassigned work done by suspect users to random
clients to ensure that our work is not compromised. As an unfortunate
result, work is duplicated.
There is no question that this method of project security is
suboptimal. We are aware of the flaws of this method and are
working to develop a new generation of clients that can produce
secure and reliable results. Jeff Lawson, distributed.net project
leader, has written an explanation of all of the considered
methods. Distributed.net users can expect to see one or more of
these methods utilized in future clients and contests.
The method used by the keymaster to decide which blocks should be
flagged for reissuing is fairly complex and varies depending on a
variety of factors. At this point in the contest, we generally
have been reissuing between 9.1% to 11.5% of received blocks.
It is distributed.net policy to give users credit for all legitimate
work completed, regardless of whether it's virgin work or reassigned
work. Accordingly, the completed percentage showed on the statistics
server represents both virgin and reissued work units, so it's
possible that we go beyond 105% completion.
Every key in the keyspace has an equal chance of being "the" key.
Statistically speaking, it was unlikely that we reached this far
in the keyspace without finding the success key. However, this is
no indication that we will not find the key. We are just as likely
to find the key as we ever were.
I apologize if I didn't address your issue specifically. I receive
hundreds of messages a day, and that load is growing exponentially
as we get further and further beyond 100% in CSC. If you need
general distributed.net support, please contact help at distributed.net.
Otherwise, can you resubmit your message to me.
Thanks for your continued support. Good luck.
Daniel Baker <dbaker at distributed.net>
distributed.net project leader
To unsubscribe, send 'unsubscribe plans' to majordomo at lists.distributed.net
More information about the plans