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


bovine [16-Aug-2004 @ 18:35]

Filed under: Uncategorized @ 18:35 +00:00

:: 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! :)

mfeiri [16-Aug-2004 @ 04:11]

Filed under: Uncategorized @ 04:11 +00:00

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

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 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 and participate
in a quick (maybe a couple of months) search for nogr20+48 using festog.


mfeiri [14-Aug-2004 @ 02:24]

Filed under: Uncategorized @ 02:24 +00:00

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

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



mfeiri [12-Aug-2004 @ 03:06]

Filed under: Uncategorized @ 03:06 +00:00

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


chrisj [23-Jul-2004 @ 08:46]

Filed under: Uncategorized @ 08:46 +00:00

:: 23-Jul-2004 08:46 GMT (Friday) ::


As some of you may have noticed, an album for user photos has been added to This currently contains old photos (some up to
4, 5 years old).

Obviously, we need some more recent ones in there :)

If you’d like to be featured, email submissions to “” –
ensure photos are G-rated ]:8)

(staff photo’s are already in there :)


bovine [19-Jul-2004 @ 19:51]

Filed under: Uncategorized @ 19:51 +00:00

:: 19-Jul-2004 19:51 GMT (Monday) ::

A number of new release candidates have been added to the pre-release
page at for people
who want to help test new versions prior to formal release.

A new Mac OS X client has been moved from the pre-release page to the
official release page, that incorporates even more PPC speed
improvements for OGR.

Kakace has been working very hard to bring forward these exciting PPC
speed optimizations. There will be hopefully be more OGR gains for
other architectures in the next few weeks, once some major OGR core
cleanup and improvements are finished.

I’ve also made available version 1.3.0 of my Win32 LogVis add-on. It
is available on and
source for it is on Since everyone
likes looking at screen snapshots, here are a couple for you all:


nugget [17-Jul-2004 @ 09:47]

Filed under: Uncategorized @ 09:47 +00:00

:: 17-Jul-2004 09:47 GMT (Saturday) ::

The fine folks at are now selling some really cool t-shirts
with the cow on them. I’ve updated the dnetware web page to
point to their affiliate storefront, but you can go straight
there from here:

Sport some stylish fashion and help out at the same time. ]:8)

(the “Moo Country” shirt is my favorite, don’t miss the image on the back)


bovine [01-Jul-2004 @ 06:56]

Filed under: Uncategorized @ 06:56 +00:00

:: 01-Jul-2004 06:56 GMT (Thursday) ::

Just a networking status report to say that the IP address of the
statsbox was changed a couple hours ago, to accommodate for an ISP
change at the facility where it is hosted. The DNS entries for it
have already been updated and most people should still be able to
access it at the usual without any
problems, but some people might still have problems for a few more
hours if your DNS servers are not honoring the TTL durations properly.

There is also currently a slight networking glitch that is causing
some backlog of the fullservers reaching the keymaster, but the
buffered nature of our fullserver network should minimize the impact
on any clients. The problem is expected to be resolved within a
couple of hours and the backlog should catch up soon after.


bovine [28-Jun-2004 @ 08:48]

Filed under: Uncategorized @ 08:48 +00:00

:: 28-Jun-2004 08:48 GMT (Monday) ::

Two new release candidates have been made available on the pre-release
page for v2.9008.492: This includes a Mac OS X client with some
additional PPC OGR performance improvements. There is also the first
native 64-bit Win64 client (you must have an AMD64 or Intel EM64T CPUs
running a beta release of “Windows 2003 for 64-bit extended systems”).

I also thought I’d mention that we are approximately 90% done with the
OGRp2-24 already, including the verification pass. (For the OGRp2-25
we are only a few percent done so far.) We’re still working on
getting some automated reporting of the OGRp2 percentages on the stats
webpages but have no ETA yet…

Also I’d like to remind everyone to consider looking around at any old
machines that you may have installed dnetc on prior to Dec 2002 and
upgrade them to a current client version. That date was when the
RC5-72 project officially started, the v2.9000 clients were released,
and the * DNS created.

Any client that is running a version released before v2.9 should no
longer be able to work on any of the current projects and is now idle
(or working on dummy work if it is a buggy v2.8010 client). We will
be soon shutting down the * DNS entries, since we
are still getting traffic from obsolete clients trying to find work.
All current clients should already be using the *
DNS, so this should not impact clients or proxies that are working.


bovine [20-Jun-2004 @ 00:16]

Filed under: Uncategorized @ 00:16 +00:00

:: 20-Jun-2004 00:16 GMT (Sunday) ::

Many new clients have been moved from the pre-release page to the
official release page. Many of the PPC based platforms received
performance increases in this new version. There was also an updated
Win32 MSI installer. You can see the list of the updated versions at

Yesterday, starting at about Jun-19 23:30 UTC there was a short DNS
failure on one of our servers that may have caused occasional
resolution failures. There was a slight amount of backlog, but it was
caught up soon afterwards. You can see the gap where no rate data was
collected in the graphs at
Note that although the rates were missing for those times, there was
relatively normal fetching/flushing to the fullservers and the backlog was
primarily just sending to the keymaster. It is not expected that much,
if any, work was lost during that time.

« Newer PostsOlder Posts »