:: 07-May-2001 16:29 (Monday) ::

Master was down for a few hours yesterday, so stats didn’t run last night.
They’re running now, and should be complete in 6 hours or so.

:: 29-Apr-2001 21:06 (Sunday) ::

Wanted To write a little update on why the pre-release clients haven’t
been released.

A few bugs have been found that will cause functionality problems for
users. We are holding off on releasing these clients till we can resolve
these issues.

If you want to check out the current list of bugs check out
http://www.distributed.net/bugs/

:: 18-Apr-2001 16:49 (Wednesday) ::

The Following Clients have been placed/updated for pre-release:

– Windows 95/98/NT/2000/Me [x86/Zipped] v2.8015.469 2001-04-18

– Windows 3.x [x86] v2.8015.469 2001-04-18

– PC-DOS, MS-DOS [x86] v2.8015.469 2001-04-18

– Novell Netware [3.x/4.x/5.x] v2.8015.469 2001-04-18

– FreeBSD [x86/ELF] v2.8015.469 2001-04-18

– Linux [x86/ELF/all lib versions] v2.8015.469 2001-04-18

The Pre-Release Page can be found at:

http://www.distributed.net/download/prerelease.html

changes.txt file is included in the download. or at

http://www.distributed.net/download/changes.txt

Please remember to report bugs at http://www.distributed.net/bugs/

Enjoy!

:: 11-Apr-2001 10:30 (Wednesday) ::

The 4/9 RC5 statsrun died due to an mixed up logfile. I’ll be starting
the 4/9 run shortly, so 4/10 should be done some time before midnight UTC.
OGR should also run in there somewhere.

:: 24-Mar-2001 01:59 (Saturday) ::

Hi there… This is my .plan

:: 23-Mar-2001 15:24 (Friday) ::

FOR IMMEDIATE RELEASE ———————

Several distributed.net participants have expressed their concern with
regard to the distributed.net client and the recent outbreaks of
Foot-and-Mouth disease.

Some members asked if they could moove their computer with the cow client
on it, others were afraid to flush the cow, and thus spreading the disease
around the world, even to the master servers of distributed.net in the
United States.

distributed.net’s CCO (Chief Cow Officer) Jeff Lawson acted swiftly and
called his high school buddy EU Food Safety Commissioner Mr David Byrne.
Mr Byrne went great ways to grant distributed.net an exception to the very
strict transportation ban currently in place in large parts of Western
Europe.

distributed.net assures its members they can go on and flush as ever
before. There is no need to slaughter (kill -9) their cattle or let the
flushed blocks go to /dev/cesspool, as recommended by various national
governments in Western Europe. Also, piling up blocks and transport them
only after the crisis is over is strongly deprecated.

distributed.net wants to make very clear that the recent disease in some
cows, dubbed the “8012-flaw”, has nothing to do with the initial outbreak
of Foot-and-Mouth disease in England earlier this month, despite of rumors
circulating the internet.

If you suspect your cow is infected with the virus and want to be on the
safe side, go to http://www.distributed.net/trojans.html and download our
‘wormfree’ program. Be advised, though, that in most parts of the world,
virus vaccination of cows is forbidden! distributed.net will in no case
accept liability when participants get fined because of illegal vaccination.

:: 03-Mar-2001 09:05 (Saturday) ::

After many delays we are now proud to announce the availability of the
official line of distributed.net-branded clothing and merchandise,
affectionately known as “dnet-ware”. We are currently offering two styles
of t-shirts, one style of sweatshirt, coffee mugs, and mouse pads. Feel
free to cheeck out the available items on our “dnet-ware” web page at
http://www.distributed.net/dnetware/

Additionally, over the last few days we have been undergoing a fair amount
of workunit submission growth, which has been causing a backlog of workunits
to accumulate at our keymaster. In order to improve responsiveness, much
of this backlog has been transferred offline for gradual processing over
the next few days. Some new optimizations to the keymaster build 324
codebase have also been made to greatly improve sustainable workunit
processing rates by several fold under most circumstances. We will continue
to be processing the backlog over this weekend and stats should hopefully
be caught up and up to date within the next couple of days.

:: 02-Mar-2001 21:55 (Friday) ::

The Following Clients have been placed for BETA and correct the bug in
v2.8012.466.

– Windows 32bit [x86/Zipped] v2.8013.467 2001-03-02

– MacOS [m68k] v2.8013.467 2001-03-02

– MacOS [PPC] v2.8013.467 2001-03-02

The Pre-Release Page can be found at:

http://www.distributed.net/download/prerelease.html

changes.txt file is included in the download. or at

http://www.distributed.net/download/changes.txt

Please remember to report bugs at http://www.distributed.net/bugs/

These clients will expire in 7 days. We know that the windows client is
slower than previous builds. We will correct this for the real release
agent. I could tell you the whole story behind it, but it really is nothing
exciting. Just differences in compilers used…

Enjoy!

:: 28-Feb-2001 20:48 (Wednesday) ::

Nifty: http://www.ratajik.com/COWPump/

:: 28-Feb-2001 20:41 (Wednesday) ::

After Decibel’s plan from yesterday, there are some things that need
explanation. We’ve had a lot of complaints from DPC members that argued
that there was no organized megaflush going on and that the accusation
made by the DCTI staff yesterday was premature and partly false.

What seemed to be the cause for the backlog was individual team members
who saved up some blocks flushed them because they feared their 8012 blocks
would become invalid soon. A valid reason to flush, one would say.
Unfortunately it turned out that this caused a lot of blocks flushed at
the same time, blocks that normally would have been distributed over days.

Some remarks on this practice: It’s _not_ good to save up blocks. Even
when you do it only on your own or ‘just for a few weeks’. Why?

Our master is optimized for processing keys from 1 or at most a couple of
subspaces. Every subspace takes up 32MB paged-in memory. A lower number
of paged-in subspaces means a faster master. Due to the optimizations in
the code, even switching between in-core spaces means a huge performance
hit. As soon as the master process has a backlog of a couple of million
blocks from 20 or so different subspaces, it chokes.

Some people justify their flushing by saying: ‘But hey, if you can’t cope
the load of a couple of million blocks more per day, how are you going to
handle this in the future when these loads are normal?’ I hope above
mentioned explanation will show this reasoning is false for once and for
all. We have a perfectly capable master box, its specs are still way
adequate, load testing shows that when blocks are somewhat from the same
subspaces, we can easily handle 1000Gkeys/s with the current hardware.
Normally, blocks from unopened spaces are kept in a separate queue which
is processed at quiet times. When suddenly a lot of blocks come from a
lot of unopened spaces, that theoretical 1000Gkey ceiling jumps down to
a something below our current rate, hence the backlog which is very hard
to get rid of.

With this explanation I hope to have convinced people not to save up too
many blocks. Daily stats are what they are for: Daily rankings. Not for
getting a #1 spot for 1 day because you’ve saved up more or longer than
your friends. If you really want to be #1, just recruit more computers!

We try to suit as many participants as possible and we are very pleased
with all the enthusiasm distributed.net participants show. But if people
keep doing things against the policies set out by distributed.net staff,
we might have to take measures against it, by blocking people from stats
or changing the lifetime of a block. This is not because we suddenly
dislike those participants, but because we want the contests to be
satisfying for _all_ users. without backlogs, so everyone can have their
blocks tallied in time.

One more thing on backlogs: Backlogs don’t mean our system is broken, it
just means our system is handling the load sort of well. We do accept all
blocks, and never give a connection refused on our proxies. We _will_
process all those blocks in the end. Maybe not today, but eventually. So
in the end each and every blocks you flush will be counted. Your stats
total will reflect your total work done. And if we all take care in
flushing to the system as it was designed, backlogs will be kept to a
minimum and daily stats will be correct, too.

Keep on crunching!