:: 24-Aug-2004 12:49 GMT (Tuesday) ::

It looks like OGR work for 8/22 may have been credited twice, so I’m backing
that work out and re-running stats.

:: 24-Aug-2004 02:29 GMT (Tuesday) ::

I think I’ve finally got stats straightened out. The problem started when new
teams were being created and marked not to be shown. That was fixed, and the
teams created that way were changed so that they would be shown. Unfortunately,
statsrun didn’t properly handle it.

In any case, it should be caught up in an hour or two. Sorry for the delay.

:: 22-Aug-2004 17:34 GMT (Sunday) ::

I uploaded some new clients to the pre-release page a few days ago and
moved the previous pre-release clients to the formal release page at
the same time. You can see the complete list of formally released
clients here: http://www.distributed.net/download/updates.php

The pre-release clients are available for people who want to help test
clients before they are considered stable enough to be generally
recommended for all new users. There are already a few know x86 CPU
detection and core auto-selection in the current prerelease clients,
so there will likely be another batch up updates to replace them soon.
http://www.distributed.net/download/prerelease.php

There are also currently some known stats-update problems on
http://stats.distributed.net/, but we hope they should be corrected in
the next day or so. Please be patient until the issue is addressed.

:: 16-Aug-2004 18:35 GMT (Monday) ::

As previously mentioned, the work that Kakace was doing improve the
existing OGR-P2 cores has indeed resulted in further speed
improvements for even non-PPC processors as well:

On a 64-bit AMD Opteron system:
Before = OGR-P2: Benchmark for core #0 (GARSP 5.13)
0.00:00:16.33 [14,123,965 nodes/sec]
After = OGR-P2: Benchmark for core #0 (GARSP 6.0-64)
0.00:00:16.22 [23,151,097 nodes/sec]

And even a slight gain on Intel Pentium III (Tualatin) system:
Before = OGR-P2: Benchmark for core #0 (GARSP 5.13-A)
0.00:00:16.60 [8,192,495 nodes/sec]
After = OGR-P2: Benchmark for core #0 (GARSP 6.0-A)
0.00:00:25.64 [8,709,555 nodes/sec]

There will be a number of new pre-release clients made available in
the next day or so, so eager testers can look forward to playing with
them soon! :)

:: 16-Aug-2004 04:11 GMT (Monday) ::

I am pleased to announce the immediate availability of festog, an all new
cruncher to search optimal and near optimal golomb rulers.
Festog is a complete rewrite from scratch but it uses and extends (!)
techniques learned from many previous efforts by different people and
organizations. Festog stands for “FEiris Successor TO Garsp” which is a
hint to its main ancestor, the currently dominant cruncher called “Garry’s
Adaptation of Rado’s Search Priciples”.
I started to work on this rewrite in January 2002. In September of 2002
the first working code was previewed internally at distributed.net,
already including a 64bit version and entirely new ways of computing
constraints that limit the backtracking during the search for OGRs. Now,
after more than 2.5 years in the making, I feel that it is time to share
the results with the public.

Festog is now freely available as source code under a BSD license from
http://www.feiri.de/ogr/

A number of lessons learned in festog have already been used to enhance
the existing garsp cruncher in dnetc. But festog represents a whole new
platform that can use much more powerful constraints, that make it possible
to skip significant parts of the search space.

I have run a short sample stub 25/3-2-15-26-30-4 to show the difference on
my 1.25 GHz PowerBook G4:
dnetc needs 48 minutes to check 54 billion nodes to finish this stub
festog needs 9 minutes to check 7 billion nodes to finish this stub

Unfortunately these powerful constraints make festog incompatible with the
crunchers that are currently in use at distributed.net. Therefore festog
can not be used in dnetc anytime soon. But if you are as excited about
festog as I am, you can send me an email at nogr@feiri.de and participate
in a quick (maybe a couple of months) search for nogr20+48 using festog.

:: 14-Aug-2004 02:24 GMT (Saturday) ::

Just to make this clear. No, I’m afraid I cant simply build one more
client for macos classic. I have moved on to Mac OS X and I do honestly
not feel at home in Mac OS 9 anymore. Since my Titanium PowerBook died a
couple of months ago I dont even have a computer that can boot into Mac OS
9 anymore. My new Aluminium PowerBook can run Mac OS 9 in the Classic
Environment, but I rarely use this feature at all. And my old PowerBook
Duo 230 cannot boot Mac OS 9 either :-)
Additionally I think that there is probably a lot of “bitrot” [0] that
will need to be taken care of before a new client for macos could even be
built. Sorry.

Let me try to explain what it takes to resurrect the port of dnetc to
macos:

First you will need to have a working development environment to build
dnetc. An old copy of Metrowerks CodeWarrior Pro or a free copy of Apples
abandoned MPW Toolkit [1] will do. If you use Codewarrior you should take
care to get a version that supports 68k. Additionally you should get the
MrC Compiler Plugin[2] , because MrC often generated faster code than some
of the old versions of CodeWarriors own compiler.

Now, the biggest problem when porting dnetc to macos is its reliance on a
lot of unix APIs, especially in the realm of networking. In order to stay
close to the mainline dnetc codebase we have tried to use GUSI [3] to be
able to use these features under macos. Unfortunately this solution was
never without problems and GUSI seems to be orphaned now too.
Another problem are hard to trace bugs that might be related to the
unconventional way of doing multiprocessor aware threading in macos. Take
a look at bugzilla [4] and search for bugs related to macos to get an
idea.
Additionally a prospective porter would need to be able to take care of
various particularities of the old Mac OS, including the testing of the
cooperative multitasking, packaging the builds (resource forks, memory
assignment, old compression formats,…) and maintaining custom code to
make dnetc a proper citizen in a macos environment.

If you want to try it, the tarball with our public client source code [5]
should be a good place to start a new port or to resurrect the old one.

[0] http://c2.com/cgi/wiki?BitRot
[1] http://developer.apple.com/tools/mpw-tools/
[2] ftp://ftp.apple.com/developer/Tool_Chest/Core_Mac_OS_Tools/MPW_etc./Miscellaneous/MrC_CW_Plugins.sit.hqx
[3] http://sourceforge.net/projects/gusi/
[4] http://bugs.distributed.net/
[5] http://www.distributed.net/source/

:: 12-Aug-2004 03:06 GMT (Thursday) ::

I never used my .plan before, but some people might know that I used to
maintain the macos and macosx builds of dnetc during the last couple of
years. My interest has shifted towards writing an all new OGR cruncher and
Didier Levet, aka kakace, took over the maintenance of the macosx port.
Didier is doing a fantastic job! But the port to macos – e.g. System 7.x,
Mac OS 8.x and Mac OS 9.x – is now abandoned. If anyone out there feels
motivated to resurrect this port please contact me at
mfeiri@distributed.net.