:: 21-Dec-1999 03:48 (Tuesday) ::
The following clients have been updated/added:
– dnetc-macos-ppc.sit MacOS [PPC/OS8.x+/CSC]
Happy cracking!
Moose
distributed.net staff keep (relatively) up-to-date logs of their activities in .plan files. These were traditionally available via finger, but we've put them on the web for easier consumption.
:: 21-Dec-1999 03:48 (Tuesday) ::
The following clients have been updated/added:
– dnetc-macos-ppc.sit MacOS [PPC/OS8.x+/CSC]
Happy cracking!
Moose
:: 21-Dec-1999 03:01 (Tuesday) ::
…and out it goes…
ftp://ftp.distributed.net/pub/dcti/current-client/dnetc-macos-ppc.sit
Just about every major issue relating to the Mac OS client I just signed
& uploaded is covered in the Read Me.
And so, after about a month of blood, sweat and code on the part of
Michael Feiri and Don ‘Dakidd’ Bruder, we have a Mac client that builds
from the common code and is easily updated. The Mac port is here to
stay. Next up: a faceless background application…
:: 21-Dec-1999 01:44 (Tuesday) ::
The following clients have been updated/added:
– dnetc-freebsd-x86-elf.tar.gz FreeBSD x86 v2.8004.450 [ELF/MT/MMX-CSC]
– dnetc-win32-x86.zip Win32 x86 v2.8004.450 [MMX-CSC]
– dnetc-solaris-sparc.tar.gz Solaris 2.x [Sparc/UlraSparc/MT]
For those of you who always send me e-mails asking what has changed,
here you go:
2.8000
——
2.8004.450 new: macos port including Altivec core support (twice as
fast as MMX on otherwise comparable hardware)
2.8003.449 chg: win32: client sleeps for 10secs immediately after starting
as service to allow the rest of the system to fire up first
fix: all: not being able to -update if offlinemode
fix: solaris: time stamps/elapsed time on MP boxes
fix: all: clients will again reset work if the core # changes
(functionality was lost in 2.8002.446 – reset if client
version or platform changes was unaffected).
2.8003.448 new: x86: 50% faster CSC MMX core added. ‘6bit – bitslice’
replaces ‘6bit – called’
fix: all: lines in mail/logfile are no longer truncated
fix: all: pause by signal (by user) and pause by filename
are additive, that is, pause remains in effect as
long as either one is in effect.
fix: all: completed/summary time is now elapsed wall clock
time again
fix: x86: Cyrix 6×86 auto-selects CSC core #3 now.
imp: all: threads no longer check external flags for shutdown/
pause state. Flags are ‘pushed’ instead, which reduces
cache footprint.
fix: win32: win95B doesn’t have a ‘Lucinda Console’ TrueType
font, so client avoids it now.
chg: many: DES cores are no longer included
imp: all: benchmarks have greater time precision (no longer
overshoot the end of the bench period)
chg: *nix: client setsid()s and dups std handles to /dev/null
when started with -quiet/-hide
fix: dun config collision with no-networking resolved
(dun was still active even if the networking was disabled)
Happy cracking!
Moose
:: 20-Dec-1999 00:40 (Monday) ::
The following clients have been updated/added:
– dnetc-freebsd-x86-elf.tar.gz FreeBSD x86 [ELF/MT/MMX-CSC]
– dnetc-os2-x86.zip OS/2 [MMX-CSC]
The following proxies have been updated
– proxyper311-os2-x86.zip OS/2 v311
Happy Cracking!
Moose
:: 19-Dec-1999 14:49 (Sunday) ::
I’ve updated http://www.distributed.net/source/ with the latest source
code for the Win32 Log Visualizer (v1.1), the Win32 MooSounds utility
(v1.0a), and the preliminary source of the Java Log Visualizer (v0.9).
The Java Log Visualizer source was predominantly written by Willie Goo
at my request, though I did all of the parsing code and final cleanup
to get it actually working. Compiled versions of the Java Log
Visualizer have intentionally not yet been provided because it is
still a little bit aways from being useful to non-developers, however
I’m making what I have available because a number of people have
expressed their interest in helping with development. If any Java
people are interested in working on this, drop me an email since I
will likely not get too much more progress done on this soon.
I would welcome hearing from people who have suggestions or
development time to contribute to these or any other possible
utilities.
:: 18-Dec-1999 23:09 (Saturday) ::
Well, something compelled me to investigate whether all of the tables
in stats that contain block totals (there’s 3 of them) matched or not.
Unfortunately, I discovered that they don’t.
In addition to the master table, which contains 1 record for each day
that each participant has submitted blocks, there is a platform table,
which contains a row for each cpu/os/client version combination for each
day, and a dailies table, that contains info like how many total blocks
were completed on that day, how many participants, how many teams, etc.
Naturally, if you sum the blocks from all these tables, the totals should
match. Unfortunately, this isn’t the case for rc5-64.
Bruce and I have managed to correct many of these errors (including one
bad day for CSC). This means that our most astute of stats observers will
probably notice that our total blocks done will go down for both contests.
This does *not* mean that we’ve lost work, it only means that there were
some days when the statsrun goofed up and essentially double-counted the
blocks for that day. Also, from what we’ve seen, there are no cases of
errors in the master table, so personal stats shouldn’t be affected.
The bad news is that we haven’t fixed all the errors. It seems that there
was some kind of bug in the old stats code that ran on statsbox-I which
resulted in minor differences between the master and platform tables,
differences on the order of a few thousand blocks per day. These errors
will be much more difficult to track down and fix, and since they should
only affect cpu/os information, we might just leave them alone.
The good news is that, by and large, these errors disappeared when we
cut over to statsbox-II. There’s only 12 days since Feb. 1, 1999 that
have errors.
We’re beginning to work on what will amount to stats, version 3. We’ll
be adding some processes that will continuously scan through stats in
the background, looking for any anomalies like this, so hopefully we’ll
be able to quickly catch anything like this in the future.
Sorry for the confusion… keep cracking!
:: 18-Dec-1999 08:02 (Saturday) ::
Today is variety day as regards Mac OS port status updates.
The ‘cli’ client (for lack of a better term to describe what is
currently in beta) will not after all contain an Edit menu for copypaste
purposes. The SIOUX window is something to look at and (in configure
mode) use with the keyboard; it is not part of a graphical user
interface. A planned GUI app will gleefuly accept to all the clicks you
hurl at it. Until then, you can copypaste from a log.
Pre-8.0 compatibility is in the works. All linkages to Appearance stuff
has just been chucked, though networking issues remain. Bless Open
Transport.
Fractional build 449 of the Mac client does not contain the AltiVec CSC
core. That is why your CSC rates on G4s suck. It is also (I think) why
the client chooses the wrong CSC core on your cute little grey machines.
Rest assured this will change prior to the release.
More news as it happens, or very slightly delayed…
:: 17-Dec-1999 08:38 (Friday) ::
Moo.
I tinkered with stats this evening and setup CPU and OS distribution
statistics for CSC:
http://stats.distributed.net/csc/cpu.html
http://stats.distributed.net/csc/os.html
As soon as I’m completely happy with how it’s working (and get all
the proper icons in place!), I’ll set it up for RC5-64, too. That should
be in the next week or so.
Enjoy.
-dbaker
:: 17-Dec-1999 05:22 (Friday) ::
Beta 9 of the Mac Client lives.
ftp://ftp.distributed.net/pub/dcti/beta/dnetc449-macos-ppc-beta.sit
This isn’t a traditional “beta” so much as a pre-release. If you find
any major bugs, we’d of course love to hear about them, but we by and
large think we have the bug situation under control.
Major release-blockers we know about are two in number: the client has
no CSC AltiVec core (hurry up sampo!) and it doesn’t properly detect
modem connections unless you restart it after dial-up. We may go ahead
and release anyway if only one of these bugs has been fixed as of early
next week.
If you find a bug beyond these or what’s currently in Bugzilla, please
add it and/or notify me of its existence.
(Bugzilla, for your reference, is at http://www.distributed.net/bugs/ .)
The people responsible for the Mac port of the distributed.net client
are Michael Feiri (mfeiri) and Don Bruder (Dakidd). They deserve your
eternal gratitude. Send it. Direct all flames / complaints / inquiries
at yours truly instead, as the coders’ mailboxes are full already.
:: 15-Dec-1999 17:22 (Wednesday) ::
At long last the baby is here. Ethan James Wilson was born at 12:40 a.m. Saturday, Dec 11 (06:40 Saturday UTC, for all
you stats freaks). He was 8 pounds, 13.5 ounces and 20 inches. Tricia and Ethan both came home Monday, and we’re trying to
figure out what “normal” means all over again.
As you know, we will be starting work on OGR soon. OGR brings a whole mess of problems to what you know of stats today.
When keymaster hands out an OGR node, there’s no way of knowing how much work that node will require – it can even vary by
CPU. To give full credit for your work, stats will have to keep track of how much work you actually had to perform.
(You’d certainly like more credit for 10 nodes of 1000 effort than someone who did 10 nodes of 100 effort.) It’s also not
possible to say how much work we’ll have to do at the project level, so concepts like “percent done” and “odds of finishing
today” are pretty meaningless.
On top of this, we’re learning some things about managing multiple projects in a single database. Currently, a new project
means a new family of SQL tables, PHP scripts, a new import and a new stats run. For our sanity, we’d like to reduce the
duplication as much as is reasonable. I’m putting together some prototypes of options for the next generation of stats so we
can poke and prod them to see how well they work. If you notice some drool on the stats database, that’s probably because I’m
holding Ethan while typing. I’ll get it all mopped up before we do anything to the stats you know and love.
I’m also informally collecting ideas for ways we can rank individuals and teams across multiple projects. In particular, we
want to allow participation in any open project to contribute to the overall ranking. As it stands now, there’s a lot of
motivation for teams to stick with RC5-64 to protect their ranking, instead of helping out with CSC. Just think how fast we
could be demolishing CSC with a keyrate in the 80’s instead of the 20’s!
Happy cracking!