As a "loosely knit" group of computer users from all over the world, we take up challenges and run projects which require a lot of computing power. We solve these by utilizing the combined idle processing cycles of our members' computers. That's why we are called "distributed.net". Our more official name is Distributed Computing Technologies Inc. (or DCTI in short). You can read more about DCTI in our legal area or read more about our goals in our mission statement.

There are several reason's why you should join us. First of all, our main goal is to explore the possibilities of distributed computing. Together we can learn more about this exciting new form of computing. Second, if we solve the RSA Challenges, we win $10000! There's $1000 or $2000 for you if your computer is the one that finds the right key, and $6000 to the non-profit organization voted upon by the users. Third, we have some nifty statistics. The more cpu cycles you donate to our projects, the higher you will be ranked. And of course you want to stay above your friends, right? ;)

Our first victory was announced at 13:25 UTC on October 19, 1997, indicating that we had found the correct solution for RSA Labs' RC5-32/12/7 56-bit secret-key challenge. Confirmed by RSA Labs, the key 0x532B744CC20999 presented us with the plaintext message for which we had been searching for 250 days.

Our second victory was announced on February 24, 1998, confirming that we had found the correct solution for the RSA Labs' DES-II-1 56-bit secret-key challenge. The solution key was 76 9E 8C D9 F2 2F 5D EA and was found after 40 days of work.

Our third victory was on January 19, 1999 at 07:15 PST, when we found the correct key to the RSA Labs DES-III contest, with the help of the Electronic Frontier Foundation's "Deep Crack" customized DES cracker. The correct key was 92 2C 68 C4 7A EA DF F2, and it revealed the following message:

Our fourth victory was on 16 January 2000 when, shortly before 0630 GMT, we received the winning key (00438EF36FE3FC21 for you tech junkies) for the CSC contest from a Sparc in the United States after searching for 62 days. The secret message was:

The Winner is Paul Ilardi, Grad student University of Rochester. Congratulations to Paul.

Our fifth victory was on July 14, 2002 when we completed the RC5-64 project, after 1,757 days of working. The key 0x63DE7DC154F4D039 produces the plaintext output:

Visit our Press Room for more information and to read the announcements.

Founded in 1997, distributed.net has grown to become a very large network of users all over the world. Most of us just run the clients, but on our Credits page you can find the people administrating the network, coding the clients, and helping with a bunch of other things that make distributed.net work the way it does.

More information on our past or future projects, as well as the ongoing projects can be found on our projects page.

The main distributed.net web site can be found at http://www.distributed.net. Be sure to fully explore the website because there are many layers of useful information available there.

Additionally, we maintain a rather lively IRC channel on the CuckooNet IRC network. You can connect to the network using the round robin dns irc.distributed.net. Many of the distributed.net principals can be found there and even when the topic of conversation is not one of our ongoing projects or distributed.net. The quality of the discussion is usually quite good (for an IRC channel). Many talented technical people hang out on the channel and there is usually something interesting to be learned.

We also have several mailing lists that anyone can join. Once you subscribe to any of the lists, you will be able to participate in additional discussions relating to the current distributed.net projects. An archive of all of the mailing lists is also available online.

Throughout distributed.net's history, the cheerful smiling cow icon was found to have a high appeal among participants, and attempts to change the icon to something else incited panic and riots among our users. The cow icon was quickly returned.

Although in the past, distributed.net had planned to associate discinct animals for each new project ("Project Bovine: RC5", "Project Monarch: DES", "Project Kangaroo: OGR", "Project Polarbear: CSC"), many of our users indicated that they much preferred seeing a greater role given to the easygoing cow. Therefore the friendly bovine cow has now been chosen to be the official mascot for all distributed.net projects.

http://www.distributed.net/pressroom/news-20001127.html
http://www.ud.com/company/press/press_releases/11272000_2.htm

Answers in this category:
does this mean that distributed.net is owned by United Devices?
what new hardware will distributed.net be receiving?

The initial effort to win the RC5-56 contest was started by New Media Laboratories. Due to various internal factors, New Media opted to discontinue their involvement in the decryption effort. In the chaos that arose after the New Media server mysteriously disappeared, a student at Harvey Mudd college, Jeff Lawson (aka Bovine), coded the Bovine Proxy Keyserver. Initially, the goal was to allow the New Media effort to continue, storing completed keys, until the New Media server came back online. However, after it became clear that New Media would not be returning to the effort, the Key Server was modified to act as the master coordinator, completely controlling key generation and assuming full control of the effort. The rest, as they say, is history.

As the newly formed Bovine Project began to gain members, and therefore computing power, it occurred to us that a large, distributed computer like ours could be used to solve several interesting problems unrelated to RC5 or even encryption. distributed.net registered as an official nonprofit organization (officially Distributed Computing Technologies, Inc.) in November of 1997 with this new, long-range goal in mind. In support of this new goal a new class of general purpose client, is being designed. The future clients will be modular and will support any number of different, challenge specific computing cores. The completion of those clients will make it possible for distributed.net to take part in a large number of distributed computing projects at the same time.

Distributed computing can be used in a variety of situations where there is a need for a large amount of computation, but there are a number of factors that that may limit the effectiveness of distributed computing. Although it is possible to parallelize nearly any computation problem, if the "overhead" of distributing a problem is very expensive (in terms of time and/or network bandwidth) then it may actually be quicker to simply compute it on one machine instead. In general, the goal of distributed computing is to minimize the overall time required to complete a problem, from start to finish.

data-to-compute ratio

One of the most significant factors is whether or not a problem has a low "data-to-compute" ratio. This ratio reflects the amount of network communication that needs to be sent or received to each machine (from the servers), relative to the amount of computation that is performed on each machine. Problems that require a lot of data to be sent before any computation can be done may mean that more time is spent just delivering the information required to begin computation, than actually performing it. All of the projects that have been selected by distributed.net have had the property that only a few hundred bytes of data need to be transmitted for several hours of computation.

inter-node communication

Another factor that is partially related to the previous item is how much "inter-node communication" is required for a problem. Some types of distributed computing problems require that machines occasionally synchronize, coordinate, or exchange information with the other machines that are also working on the problem. Depending on the choice of implementation, this communication can be directly between machines (via direct "peer-to-peer" communication, via server-based coordination, or other techniques).

Problems that do not require any type of coordination or synchronization between machines, nor any ordering in computation of work, are commonly called "embarrasingly parallel". These types of problems are very well suited for very large-scale distributed computing since the individual pieces of work can be completed in any order, and can be redistributed to other machines if any single result fails to be returned. Depending on the type of computation being done, not all of the workunits may need to positively be completed if certain "key" results are received, or if a certain threshold has been met. All projects that distributed.net has worked on generally fit in this category. compute-split-merge.png (19.4 K)

Programming libraries such as MPI (Message Passing Interface), PVM (Parallel Virtual Machine), BSPlib (Bulk Synchronous Parallel library), and others are commonly used in scientific applications that require a high amount of precise intercommunication and syncronization between machines. These libraries generally are only usable in cluster environments because they need very fast network connectivity between machines due to the large amount of nearly continuous network traffic that is done. The fact that network communication is done between all machines in the computation also means that there generally cannot be firewalls or other highly restrictive network blocking between machines. Generally they also all require that there be very all machines remain available from start to finish of the problem. Because of these constraints, problems that require these libraries (or otherwise need a high degree of interconnect) are generally not well suited for large-scale Internet based computing. compute-cluster.png (15.2 K)

In multi-pass, server-based coordination schemes, all of the intermediate results are collected by a central server, data coordination performed by that server, and then redistributed back to machines again, if needed. Problems that rely on this technique still need to have a low "data-to-compute" ratio, since the amount of time that is spent communicating with the server and getting back another piece of work can become expensive. compute-multi-split.png (33.7 K)

public attraction and incentives

In public Internet projects like distributed.net, the machines that are performing the computational work are generally volunteered machines that are owned by other people. Therefore in order to get people to install the client on their machines, your problem will need to have some level of appeal or attraction that will make people want to donate their computer's power toward the effort. Projects that have a potential benefit for the common good tend to have high amounts of appeal (such as encouraging higher levels of data security, searching for cures for cancer/diseases). Projects that have technical appeal can also be popular among some groups of people, but are sometimes difficult to encourage wide appeal (such as proving large prime numbers, identifying mathematical oddities).

Some people are willing to allow their machines to be used for arbitrary purposes if there is the potential for significant compensation in return. (Some groups of people are even willing to permit the use of their machines for commercial purposes that would not benefit themselves or any public entity as long as they are personally compensated in some way.) Sometimes this type of compensation may mean direct compensation for every unit of time utilized, while other times it may mean a potential for a larger compensation that is awarded in a lottery-style selection process.

Other groups of people are motivated by community competition that are possible via "statistics" and ranking of the amount of computational time contributed. These groups of people enjoy "seeing their name in lights", especially if their name is ranked higher than someone else's name.

Answers in this category:
What are you asking me to do?
What do I need to participate?
What shouldn't I use to participate?
Where can I get the client software?
Does my machine need to be connected to the net all the time?
Is my modem OK, or do I need to have a faster connection?
Will my old, slow computer really help?
Won't I get in trouble for trying to crack encryption?
Where can I get help installing the client?
Where can I get more information on distributed computing?
Who else is involved?
Should I leave my computer running all the time if I am running the client?
Isn't it bad to leave your computer running all the time?
Doesn't running the client waste a lot of electricity?

To accomplish this great computational task, we need you to help out by running a special client program on your computer and allow it to connect to one of our coordinating proxy keyservers. When the client program starts for the first time it will contact a keyserver and request one or more keyblocks. When finished it will begin testing the keys looking for the one that deciphers the contest message. When all of your keyblocks have been tested the results will be transferred back to a keyserver and a new set of keyblocks will be downloaded. The amount of time it will take your computer to test all the keys in a block depends on the type and speed of the computer. Very slow systems might take as much as 12 hours per block whereas the fastest multi-CPU systems can do a block in under 3 minutes (search the Client Speed database for more information about your particular computer).

All you need is a computer that is occasionally connected to the internet (once every couple of days, say).

You shouldn't run the client on any machine that you do not own or administer. For instance, it is considered bad form to run the client on your ISP's servers without their knowledge or permission. For more on this important topic, please read thoroughly our Official Policy page.

All currently available client packages are available at http://www.distributed.net/download/clients.php

If you would rather download the clients via ftp, all clients can also be found at ftp://ftp.distributed.net/pub/dcti/current-client/

Absolutely not! The clients have the ability to fetch work to be completed at a later time when your computer is offline for example. If all this work is completed before the computer reconnects to the Internet then the client will continue working until the network is available. This allows any machine, even one that is only online once every couple of days or so, to work continuously.

Any modem is just fine! Your computer will only want to communicate when it needs to download new work or report the status of the work it has done. Depending on the buffer sizes you select and the speed of your computer, this may only need to happen once every several days. The amount of information that is transferred to and from your computer is tiny (about 125 bytes per block for the RC5 challenge, for instance) so even when moving a large amount of work over a slow modem it doesn't take too long.

The key to completing our projects in a reasonable period of time is to get more computers, not necessarily more powerful computers. The computing power of the world's fleet of aging 386s and 486s far outweighs the (idle) computing power of any supercomputers we could conceivably recruit. An interesting point to consider: the DES contest message was deciphered by a Pentium 90 running FreeBSD with only 16 megabytes of RAM. Not big iron by a long shot. Both the 48-bit RC5 and the 56-bit DES challenges were cracked by machines not even in the top 20 in the stats. Everyone has a chance of finding the correct solution. Every computer contributing to the effort is an asset.

Note: Very old machines (pre-386 class) cannot be used at the present time. The RC5 algorithm, for instance, depends heavily on 32-bit data manipulations. The current set of clients all use 32-bit code that won't execute on these earlier machines.

Some of our projects, including RC5, DES and CSC, involve cryptography. There is nothing illegal, immoral, or dishonest about what we are trying to accomplish. These are legitimate contests sponsored by legitimate and respected organizations (RSA Data Security, Inc. and CS Communications & Systems). We are trying to decrypt encoded phrases which have been released to the public specifically to test and evaluate the strength of the encryption algorithm used in each contest.

You have several ways of obtaining help. First, check out our Faq-O-Matic section for the Client software. You can also send mail to help@distributed.net, visit us on the CuckooNet IRC network in channel #distributed, or join one of the mailing lists found at http://www.distributed.net/discussion/. You may also find the step by step guide to installing your first client useful.

• Read our How To Help section.
• Read the other pages in these FAQ-o-matic pages.
• We have some Mailing lists you can join.
• For our international members, you can contact your Regional Representative, who will answer your questions in your native language.
• There are always people online on our IRC channel #distributed on CuckooNet (irc.distributed.net).
• Just browse our site; you'll definitely read a lot of interesting things!

Disk access frequency is not really a factor in HDD failure. Most of the drives that failed on my machines were backup drives which were used relatively infrequently.

Most people now accept that the easiest way to achieve hardware reliability is to have a machine in a cool low humidity environment, to turn it on, and leave it permanently on. Start up loads are far more damaging than continuous use. In my opinion, the biggest factor on how long drives last is background vibration, humidity, and how well they are cooled.

I also have some good news: this effect is usually minimal, and chances are the machine will be hopelessly obsolete before it breaks even under 24/7 conditions.

Many modern computers can enter low power-usage states when they detect they are idle. This mostly involves powering down the monitor, stopping the hard drive, and allowing the CPU to enter a slower idle state that does not produce as much heat. Running the client on a normally idle should not affect its ability to power down the monitor, which is a significant part of the power usage.

However, the hard drives of a power-saving machine may be prevented from spinning down if the client continues to periodically save or load blocks to disk. If you have multiple hard drives in your machine, you may want to consider ensuring that your client buffers and logs are on the hard drive that is most likely to have other activity as well (such as your OS swap file, or OS System directory), allowing the other less frequently accessed drives to spin-down unaffected. You might also want to consider enabling the Client's "nodisk" mode so that it only uses RAM for its operations, but be aware that your work may be lost if your computer crashes or loses power (wasting the power and idle cycles that the client could have used for productive work if it wasn't lost). You might also want to be aware of the fact that spinning up/down your hard drives can actually reduce its lifetime.

Additionally it is true that the Client will also probably prevent your CPU idle from entering its reduced power consumption idle cycle mode (sometimes called "HLT" mode in x86 processors). However, the actual power consumption by the CPU processor alone is actually a minor portion of the total usage by the computer (much less than 20% usually), and entering the lower usage idle mode only reduces that amount slightly. Note that this idle mode is unrelated to the CPU frequency-lowering that is sometimes done automatically by APM services when no user interactivity is detected (the client will not interfere with this reduction). You should also be aware that sometimes computer fans run only when excessive heat is detected (such as from a continuously operating CPU or hard drive). These cooling fans are an additional source of power usage.

Overall, the actual difference in power consumption by computers that are running the client during periods of time when they are normally left on (for unrelated purposes) is very minor. Distributed.net's purpose is solely to use the idle cycles that would normally be unused.

Teams

Technical info about statsbox

Client speeds database pages.

Answers in this category:
Where can I find information of distributed.net's progress?
Are there any charts or graphs?
Can you please explain the statistics?
How often do stats update? When does that happen?
What is UTC? Is that like GMT or something?
How come stats don't update more often?
How come I haven't received my password?
I'm losing my old email! Will all my stats be lost?
Do random blocks show up in stats?
I think it would be really neat if stats showed X. Why doesn't it?
I lost my stats password and lost access to my old email account.
Why can't I retire more than 10 email addresses into one?
I'm missing work units!
I mistyped the email address in my client and it has shown up in the stats. Is there any way for me to get credit for those work units?
Stats are messed up! Some guy just jumped up 1,000 places in the ranking but only did a few blocks yesterday!
It's been over 24-hours, where are my stats?
Why do statistics not update some times?
Why is arbitrary HTML no longer allowed in team or participant mottos?
The size of text on my stats page is too big/small

A tutorial on statistics is also available to guide you through our stats system.

Answers in this category:
I can't figure out how to join a team!
I created a team, but it never showed up like it was supposed to! Obviously, I can't join the team
I administer a team, how do I let my team members see who is on my team? Can I keep them from seeing who else is on my team?
How do I un-affiliate myself from my former team?
I administer a team, and I would like to donate my team's blocks to another team. Can this be completed?
I am a member of a team, how do I check who else is on my team?
I have already checked and uploaded a couple hundred blocks. I'm not on a team. I'm wondering: will these will be credited to the team I sign up for, or have they become the domain of distributed.net?
You should add a link to everyone's summary page that shows what team they are on
Can you tell me more about teams?
How come a team just went up several places in the overall ranking, but did less work yesterday than other teams?
I created a team a few days ago, but stats says it's 100 days old!

Before you can join a team, you must first have your password (see How come I haven't received my password?). Once you've gotten your password, and you've successfully edited your participant information, then you'll be in a position to join a team.

The simplest way is to simply go to your team's stats summary page and click the "I want to join this team" link. You'll be presented with a login dialog box where you should enter your email address and your password.

That's all there is to it!

Perhaps there is a "team creation" faq out there that gives erroneous instructions, because this question is actually pretty common. When you created the team, it was explained pretty clearly so I'll simply repeat here in the FAQ what you read when the team was created:

This is a commonly-requested feature, but it's our view that a person's team membership is private and to display that on stats would be a violation of participants' privacy.

Imagine a controversial team, like a pro-life team or a drug-legalization team. It's concievable that a person might wish to support that team by being a member yet wouldn't want to advertise their support or make it known that they are on that team.

Or, imagine being a participant in the top 10 who is not on any team at all. That person would (due to the suspicious lack of a team affiliation line on their summary) likely be deluged in requests to join people's teams. "dood! you rool! join team luser!" We'd prefer to allow people to participate individually in peace and privacy.

To offset this, please feel free to mention your team affiliation in your participant motto, which shows up on your summary page. The motto allows html, so you can even embed a link if you wish. We feel that this compromise is the best of both situations.

To make things more interesting, some people have decided to work together in groups (rather than individually) and thus increase interest and participation. It is important to note that this is not about one team versus another, or about who actually cracks the key. This is an effort to demonstrate that a collection of amateur internet enthusiasts can break strong 64-bit encryption using only their existing computing resources.

Teams are optional! They are fun and the rivalries between them help to increase project participation but you are not required to join a team if you don't want to. Also there are no official teams for anything. Some people might claim that their team is the official team for an operating system or group, but you are not required to join it. You can simply run for yourself, or run for others if you wish.

For those of you who participated in the Bovine RC5-56 project you should be aware that teams are being handled differently this time around. Previously a team was identified by the email address of the team coordinator. To join you had to submit blocks using that address. This time around we have set up a true team structure. Individual contributors should report all checked blocks under their OWN email addresses. They can then choose to affiliate themselves with a particular team. If they do so their individual stats will continue to report their total effort but their contribution will also be counted in their team's total.

If you want to create a new team, simply visit http://stats.distributed.net/newteam1.php3 Be sure to carefully read the notice that appears. You only need to register if your team doesn't already exist. If you really mean to join a pre-existing team proceed as follows. First, get the ID number of the team you wish to join (this can be done using the Search for Team facility on the stats page). Then, from your individual stats summary page, you can affiliate yourself with your team by choosing the Edit Participant Information button. Note that this last step requires a password. If you don't already have one you can get one automatically mailed to you from the link at the bottom of your individual stats summary page.

One other note about joining teams. If you've never joined a team before then ALL the blocks you have checked will go to bolster your team's stats when you join. If you do already belong to a team and then switch to a different one only new blocks that you check will be attributed to your new team. Old blocks stay with your old team. In either case your individual stats always show your total contribution since starting the effort regardless of whether or not you have joined a team or switched teams.

The confusing part is that team X's summary page won't show 50,000 blocks being done yesterday. They will move up a large amount in the overall ranking, even though they did very few (or even 0) work units yesterday.

This is intentional. Those 50,000 work units might have been assigned to the team yesterday, but they weren't actually submitted yesterday... they were submitted over many days or even months.

See also: Stats are messed up! Some guy just jumped up 1,000 places in the ranking but only did a few blocks yesterday!

If a participant joins your team and brings with them blocks which they've done in the past but have never assigned to a team, then your team will get credit for all those blocks on the days that those blocks were actually completed.

Answers in this category:
What type of machine is the stats server running on?
Can stats processing be distributed to other computers?
Neat stats. Do you, like, use Cold Fusion or something?

• HP ProLiant DL140 G2 server, 1U rack mount
• Dual processor, Intel Xeon CPU 3.40GHz with HyperThreading (total 4 logical processors)
• 8.0 GB RAM (4 of 8 sockets filled)
• 2TB usable, mirrored with ZFS (2 x 2TB SATA disks)
• Operating system is FreeBSD 8.1 for AMD64
• Web server is Apache and PHP
• Database is PostgreSQL 9.0.1
• Donated to distributed.net 2010-09, Put into service 2010-11-26.
• Picture: link

• Dual-Processor AMD Opteron 244 1.8GHz
• Rack Mount 3U Chassis (9 x SATA drive bays)
• Tyan Thunder K8S Pro (S2882) motherboard
• 4.0GB RAM
• 3Ware 9550SX-8LP SATA RAID Controller
• 600GB RAID 10 (6 x 200GB disks)
• 300GB RAID 1 (2 x 300GB disks)
• Operating system is FreeBSD 6.x for AMD64
• Web server is Apache and PHP
• Database back-end is PostgreSQL 8.1
• Purchased 2004-04, Put into service 2004-04, Taken out of service 2010-11-26. (In service 6.5 years)
• Pictures: link, link

• Dell PowerEdge 6400 Quad-Processor Pentium II Xeon 450-MHz
• Rack Mount 7U Chassis, huge! (8 hotswap drive bays)
• 2.0GB RAM
• Dell PERC RAID Controller
• 104814MB RAID 5 (3 disks)
• 17278MB RAID 1 (2 disks)
• Operating system is FreeBSD 4.x
• Web server is Apache and PHP
• Database back-end is PostgreSQL, transitioned from Sybase ASE for Linux (running in Linux binary emulation mode under FreeBSD)
• Build began 2001-05, Put into service 2001-12, Taken out of service 2004-04. (In service 2.4 years)
• Picture: link

• Dual-Processor Pentium III-500 (Asus P2B-DS motherboard)
• 512Mb of RAM (two of four DIMM sockets filled)
• 13Gb of u2w-scsi hard drive (a nine and a four)
• Operating system is Linux 2.2 kernel
• Web server is Apache and PHP.
• Database back-end is Sybase ASE for Linux
• Build began 1999-01, Put into service 1999-02, Taken out of service 2001-12. (In service 2.8 years)

And prior to that, statsbox-i:

• Pentium 166 overclocked to 200MHz
• 128MB of RAM
• enough IDE drives to be a major bottleneck.
• Taken out of service 1999-02.

This database is useful primarily for comparing the relative performance between different processor models. It can also be very useful for determining if your system is running the client as fast as other users are, and can help identify the existence of potential hardware configuration problems.

Keep in mind that the Client Speeds Database pages are completely unrelated to the Participant and Teams Stats database that shows your cumulative amount of work completed. The Client Speeds Database is meant purely to show the representative speed that a single client on a single processor type/speed can expect for a single benchmarked block.

My computer's speed is significantly slower/faster than the other entries already reported for my system!

What about benchmarks of multiprocessor machines?

Errors in the speed database:
I've found a speed in the database that is obviously incorrect.
What are the StdDev and StdErr% columns?
What is the "Record id" column?

New entry submissions:
What is the best way to determine benchmarked speeds for entry to the database?
My CPU, Operating System, or client Version is not one of the available options.
When I submit a new entry into the Speeds Database, what is the email used for?

• your PC's memory cache is disabled (try looking in the BIOS).
• the MHz of your processor is actually different from what you think it is.
• the client is selecting (or has been configured to use) a core that is not the optimal core for your processor.
• there is another hardware fault, such as bad RAM, a faulty timing clock, or something else that is causing the system to generally perform poorly. Usually you will notice related symptoms in other use of the machine too.

The primary purpose of the separate multi-processor speed listing is to provide a single page that summarizes the types and speeds of the available multi-processor machines on the market against each other. Also many casual users simply aren't familiar with the availability/limits of specific processor counts for different architectures, and these multi-processor speed pages gives those users a convenient place to find that information.

Please keep in mind that the benchmark speed reported by the client is always for one processor! When submitting the speed for a multi-processor machine, you will need to manually multiply the single-processor before entering the speed within the submission form.

Sometimes people accidentally submit speeds into our database that is obviously incorrect, for reasons such as the following:

• entering the speed measured in kkeys or mkeys instead of whole keys.
• selecting the wrong processor model.
• selecting the wrong client version (and hence project type).
• typo in data entry.
• intentionally entering an incorrect speed just to be malicious.
• intentionally entering a benchmarked speed that was reported by the client, but under anomalous conditions (such as on a machine with faulty RAM, or disabled cache, or on a heavily loaded machine, or on a machine with a faulty clock).

If you suspect that you've found such an entry, use the "submit a bug request" link that is on the front http://www.distributed.net/speed/ page and we will manually remove such entries.

StdDev represents the "standard deviation" of all reported speeds for that CPU MHz. The standard deviation is a statistical figure that can be used to determine the typical range in which all of the reported speeds lie within. Typically when there is a high amount of correlation between all of the reported values, then a high majority of the values will lie within reported the mean spead +/- the standard deviation amount. Values that lie outside of that range have a greater possibility of being anomalous.

StdErr% is simply a different representation of the standard deviation. It is simply the result of the following (stddev / mean * 100). StdErr% is useful for comparing the relative amount of deviation between each of the values within the summary listing pages. Typically, if the StdErr% exceeds 15% or 20%, then there is a high amount of deviation within that group of values, and one or more of the values is anaomalous to a large degree.

If your processor, operating system, or client version is not one of the available options, then go back to the main speed index page and use the bugzilla link at the bottom of http://www.distributed.net/speed/ to report the value that you need.

Please make an effort not to submit bogus or invalid values. If you know that your speed value is suspiciously higher or lower than any of the other values reported by others for similar hardware, then recheck your values. Similiarly, if you know your system is grinding to a halt and about to crash and the speed reported by the client is totally non-sense, then don't report that value! Additionally, don't report excessively high/low values for favorite/hated operating system. The purpose of this database is provide a useful comparison for other users, not to promote platform advocacy or advertise bizarre values. By not submitting these bad values, you will save us the effort of having to remove it later.

Current Ranking -- team and individual summaries
This shows how the given team or individual is ranked compared to other teams or individuals taking part in the project.

Total blocks to search -- all summaries
The RC5-64 keyspace is comprised of approximately 18 million million million keys. Bovine has organized these into keyblocks. Each keyblock contains 268,435,456 (2^28) keys. There are 68,719,476,736 (2^36) keyblocks covering the entire keyspace. Keyblocks are the fundamental unit of progress in the Bovine stats system. The network of proxy keyservers doles out groups of keyblocks to the clients to be tested. One of these blocks contains the encryption key we are looking for!

Total blocks checked -- all summaries
The number of keyblocks that have been tested and returned to Bovine so far.

Keyspace Exhausted -- all summaries
The portion of the total keyspace covered by the checked keyblocks expressed as a percentage.

Total keys checked -- all summaries
The total number of keys that have been tested. It is equal to the number of total keyblocks tested multiplied by 2^28.

Time Working -- all summaries
The amount of time, expressed in days, that the project, team or individual has been working on the effort.

Overall Rate -- all summaries
The average keyrate that the project, team or individual has sustained since they began working on the contest.

Keyblocks and keyrate for yesterday -- all summaries
This area shows the total number of keyblocks checked in the last 24 hour period (from 0:00 to 0:00 UTC) and the keyrate corresponding to this number of blocks.

If you need help figuring out what time UTC is in relation to your local time zone, this page may help. The trick is to remember that UTC doesn't change for daylight savings time.

If you're really curious about the difference, feel free to bore yourself to tears with the details.

It's really in everyone's best interest if your clients only flush blocks once a day or so. When stats updated more frequently than daily, some people changed their client configuration to run the smallest block sizes and to flush after every block. This creates needless network traffic and makes for larger log files on the keymaster.

Besides, in a project that's taken over a year, does it really matter how many blocks you had done *at noon*? Daily updates are quite sufficient for tracking the progress of the project.

Your stats password will not be automatically emailed to you once you join one of our projects. You will need to request your password by clicking on the link at the bottom of your personal stats page. You must first access your personal stats page by entering your complete email address in the "Participant Search" form located at the top of most stats server pages.

Note that in order to be able to request your password from your participant stats page, you will need to have entered a valid email address in the client configuration menu, flushed some work units back to the proxies, and waited up to 24 hours for the stats server's daily update that will detect that you have joined distributed.net.

To do this, you need a couple things:

• You need to know the password for the email you wish to retire
• You need to configure your clients to use your new email address
• Your new email address must appear in the stats database

Once all those things are in place, you simply visit the configuration page for the old email, and click the retire link. The script will walk you through the procedure of selecting your new email address and performing the retire.

You might assume, though, that the odds of duplicate random blocks is quite slim but in reality that's not always the case. There are two additional factors involved. Random blocks are not chosen from the entire 2**64 keyspace, but rather we've pre-defined some slices of keyspace as random slices, and when your client picks a random block it will come out of one of these areas. Which slice to use is determined by the keymaster and communicated to your client when it connects to the network. What this means is, the ratio of tested / untested keys in a random prefix can vary tremendously. As more and more random blocks are turned in, the current random keyslice gets more and more full and the odds of your client picking a duplicate block increase.

While allowing the clients to pick randoms from the entire keyspace might seem an attractive concept, there are two reasons why this is not wise. First, it wouldn't make any sense if we were 90% complete, since 90% of all randoms would end up as duplicates. Secondly, we are unable to track the entire keyspace on the keymaster. We can only accept blocks from "open" keyslices that are being actively tracked. If a block arrives at the keymaster for a keyslice that isn't open, it is discarded and will not be reflected in stats. Since we are limited in the number of keyslices we can simultaneously track, it's necessary that we be able to control which areas from the keyspace a client pulls random blocks from.

• We have day jobs and - in most cases - lives. We can't spend days at a time developing new code for the stats server. Many suggestions we hear are already on a todo list, just waiting for us to have enough time to implement them. We're an all-volunteer army, and we're always looking for new recruits. If you have serious SQL experience, especially with VLDB's, let us know you want to help.
• Most new statistical facts require more space somewhere. The largest tables contains several million rows and occupy several gigabytes on disk. At this scale, adding even a single integer field (4 bytes) can add almost 100MB of additional table usage. Even if we decide a stat is worth the extra space, it's not something we're going to rush into. Adding a field requires shutting the stats pages down completely for a period of hours, and introduces the possiblity of breaking something somewhere else. We don't take these risks lightly.
• Most new statistical facts require more time to calculate. Typically, the daily stats run takes around 4 hours a night, during which parts of the stats pages are shut down. If we tried to implement every idea suggested, we could easily fill up a 24-hour stats run with no time left over for viewing your stats! Ranking alone consumes almost an hour - adding a second ranking statistic would add another hour to stats.
• Some new statistical facts require information not currently returned from the client or not returned from every client. We can't report on what we don't know.
• It could be we don't know how to calculate such a thing, that your request doesn't make sense within the current framework, or that we just don't understand your request. Be as specific as possible. If you know something about SQL, feel free to show us an example.
• Providing a statistic may reveal confidential information about other participants. In particular, we will not reveal all or part of an e-mail address or name without permission, and we will not reveal team affiliations.
• We may choose not to add your feature because we think it may not have enough appeal to others, would be easily misunderstood or would encourage the wrong behavior in participants. Hourly or up-to-the-minute stats fall in the "wrong behavior" category.
• Some stats are more easily provided by forming a team, or by using a personal proxy and analyzing the logs yourself. There are a plethora of log analyzers in our third-party addons page at http://www.distributed.net/download/addon.html
• Even if you suggest a great idea, with no measurable impact on space or speed, it could take us days or weeks to get around to it.
• Though most of us do hang out in #distributed from time to time, we don't always hear everything that goes on there. If you have a suggestion, add it to Bugzilla, don't just rant.

We recognize that some users may need to legitimately retire more than 10 email addresses, and we will personally address these issues on a case by case basis. If you fall in this category, please send email to our general help email address describing your problem.

Please note that we do *not* support retires as a way of creating 'sub-teams'. We know that a number of participants would like to see this feature implimented, and it is on the to-do list. Please be patient, as this type of change is a lot more complicated than it looks, and it will take some time for us to devise a system to handle it.

There are many reasons why work units could be 'disappearing'. One reason is latency. Our network is designed for maximum uptime and redundancy. This also means that it does not operate real-time... it takes some time between when you submit a work unit to a fullproxy and when it actually gets to the master. The stats are based on when a block is received by the keymaster, not when it was completed by the client. So if you flush at 2300UTC, those blocks might not make it into that night's statsrun. This means that you can not look at any single day and determine that you are missing blocks... they might show up tommorow, or even later. In extreme cases, we've even seen work units get delayed by 2 weeks.

If you are submitting work to a personal proxy (any proxy not officially run by distributed.net) then we can not guarantee that that work will make it to our network. This is because we can not control personal proxies. The person running a personal proxy can easily delete any work that has been submitted to the personal proxy without actually submitting the work to our network. Or their computer could crash. Or their dog could eat the blocks. You get the picture. }:8)

There are also client versions that are specifically ignored by the network. Currently, any client older than v2.8015 is ignored. You can read more about this here and here.

Many people have been confused about OGR stats. OGR is an ongoing projects, but it is divided into many small projects. The results for these seperate projects are reported seperately by stats, so please make sure and check any available OGR stats before reporting missing work.

If you still feel the need to contact us about missing work units, please follow these guidlines:

• It is very important to have logfiles so that we can see exactly what the client or pproxy is doing.
• There should be a history of missing blocks. Please do not contact us because your stats were low for a single day.
• Please check the .plans periodically. We do occasionally experience problems that will cause everyone's stats to report as low for a day.

However, since the blocks in question weren't done yesterday, but rather are the result of their previous work under another email address, they have no impact on "yesterday" stats or the reported block count from the previous day.

See also: How come a team just went up several places in the overall ranking, but did less work yesterday than other teams?

The key to this "24-hour" value is that the client has actually returned completed work to the distributed.net servers. If this is done, prior to 0:00 UTC, then you will receive credit for your work and should see your stats the "next day."

To return completed work to the distributed.net use the "dnetc -update" command or right-click on the cow-icon and choose "update." This command will force the client to "flush" (or return) work to the distributed.net servers. Note that you must be connected to the internet in order to accomplish this task.

The client, by default, can be configured a variety of ways to return completed work as the user desires. This can be done with changing the "Buffer Threshold" and/or the "Client Connectivity". Refer to these other topics for additional help: How do I make the client start/stop/fetch/flush/etc at specific times of the day/week? I use a modem. How can I get the client to download enough packets? How can I fetch enough work for when I am offline?

Also some times the log files are not correctly transfered between tally and the keymaster, which again requires manual intervention to get them running again.

Your best bet is to check the .plans which are located at http://n0cgi.distributed.net/cgi/dnet-finger.cgi for more information, or visit us in #distributed on irc.distributed.net (most of the time people there know what's going on!)

Although it was not something we wanted to do, without restrictions on content, it was possible for malicious javascript to execute and leverage your logged-in team and participant password to alter your membership, including switching you onto different teams. Allowing arbitrary HTML or Javascript to execute from within the domain of *.distributed.net could also allow the compromization of secure cookies used by the stats site to remember your login. As you can imagine, this is a significant vulnerability and we need to treat security issues seriously.

Attempting to filtering general HTML is what a number of web-mail providers (like Hotmail, YahooMail, and others) attempt to do today, but if you've kept up on monitoring security vulnerabilities mailing lists (such as BugTraq or Vuln-Dev), you're probably aware of incident after incident of new tags being discovered that needed to also be filtered. These new discoveries have continued to occur every few months for the last several years, ever since the popularity of web-based mail took off. E-Bay also attempts to allow auctioneers to utilize HTML for their product descriptions, but they also need to filter malicious techniques that can be used to automatically submit bids and such. There are many other instances of websites that need to employ similar tactics.

There are many ways to include malicious javascript in arbitrary HTML: you can attach OnLoad/OnOver/OnFocus events to most HTML elements. Cascading style sheets can be used to add extended behaviors to other types. The "javascript:" protocol can be used anyplace an URL can be referenced. Inline <script ...> blocks can be used. Plugins/ActiveX can be invoked through a variety of techniques including the <embed ...> or <object ...> tag and potentially invoke holes that exist in those plugins. Frames can be created with <iframe ...>, <frame ...>, <layer ...>, or <span ...> that reference other websites and load unsafe code that can manipulate the main page's namespace through webbrowser bugs. It's possible to use <meta http...> to trigger refreshes to other locations or submit automatic responses to other pages on our website. Other URL protocols, such as "file:" or "money:" or "telnet:" can be used in some cases to reference local resources through some types of browser bugs.

An additional part of the difficulty is that web browsers are designed to be extremely tolerant of HTML that they parse in the interests of being most compatible (but each browser is tolerant in different ways). Different browsers allow different encodings throughout their documents. For example, "<script%20language= javascript>", "<script >", "< script>", and hex-encoded, mixed-case, and unicode/foreign character sets provide equivalent ways of expressing the same thing.

Two well-written security advisories on this type of exploit are available from CERT:
http://www.cert.org/advisories/CA-2000-02.html
http://www.cert.org/tech_tips/malicious_code_mitigation.html

Within the last month alone, there have been numerous cross-site scripting issues exposed throughout the web on extremely popular websites. Here are just a few of the articles on BugTraq within the last month that succinctly summarize the variety of the problems:
http://archives.neohapsis.com/archives/vuln-dev/2001-q4/0907.html
http://archives.neohapsis.com/archives/bugtraq/2002-01/0093.html
http://archives.neohapsis.com/archives/bugtraq/2002-01/0252.html
http://archives.neohapsis.com/archives/bugtraq/2002-01/0268.html
http://archives.neohapsis.com/archives/bugtraq/2002-01/0038.html
http://archives.neohapsis.com/archives/bugtraq/2002-01/0047.html
http://archives.neohapsis.com/archives/bugtraq/2002-01/0072.html
http://archives.neohapsis.com/archives/bugtraq/2002-01/0178.html
http://archives.neohapsis.com/archives/bugtraq/2002-01/0207.html

In summary, it is an ongoing job to maintain filters that attempt to explicitly exclude "known unsafe" activities, and we do not have the resources or desire to maintain such filtering technologies. It's far easier to do the opposite and create a filter that only allows "known safe" activities. Although it would be possible to try to construct a filter that allows good-HTML to be entered (but be very aggressive and only allow "known safe" forms), it's a little easier to create your own variant that does not have any of the operational expectations that HTML has. Attempting to filter HTML also has the problem of inadvertantly breaking "safe" HTML that simply does not conform to the strict filtering rules that would need to be used (after all, there are innumerable ways of expressing the same effect).

By creating our own markup language that is extremely limited and extremely strict in its allowances, there is far less ambiguity over why something isn't working or what is allowed. In actuality, the markup language that was chosen to be implemented is intentionally similar to the markup language used by UBB/phpBB/vBulletin and a number of other bulletin-board packages available today, so as to reduce the "non-standardness" of our technique. The available tags are shown on the team and participant configuration pages.

However, it also ensures that users can increase/decrease the font sizes as they see fit(there should be keyboard shortcuts to do this in all modern browsers) and have the browsers automatically adjust the font sizes accordingly.

Is there a basic tutorial on how to setup the client?

How do I run the client?

How do I remove a client from my system?

How can I make the Windows client startup in the tray?

Automatically starting the client at boot time

What command line switches/options does the client support?

Can I configure multiple clients/machines with one d.net ID (email address)?

How can I get the client to use all of the CPUs in an SMP system?

How can I automatically deploy/upgrade clients in a LAN environment?

How do I specify separate configurations for clients running from a shared network drive?

What are the requirements of the Windows MSI client installer?

What are the special features of the Windows MSI client installer?

What can I insert for the param <prj>?

General client-keyserver communications answers:
Is there a basic tutorial on client<->keyserver communications?
What if I am behind a firewall?
How do I make the client start/stop/fetch/flush/etc at specific times of the day/week?
Why do I keep getting network errors, or problems resolving hosts?
I have a computer without a network connection. How do I "Sneakernet"?
Can I get and send work units through email?
Can I share the buffer files across a network?
I set my client to receive a certain blocksize, but I sometimes notice smaller blocksizes being retrieved.

Dial-up networking specific answers in this category:
The client tries to trigger auto-dial, but fails because my dialup needs a password
I use a modem. How can I get the client to download enough packets?
The client triggers auto-dial too much, or does not disconnect.
How can I fetch enough work for when I am offline?

Answers to common starter questions:
I'm confused about keys, stats units, nodes, stubs, packets, blocks, work units,...
The client uses 100% cpu time on my computer!
My client is switching between projects instead of working only on my first choice
How do I make the client spend X% time on OGR and X% time on RC5?

Partial blocks, work resumption and the crunch-o-meter:
What if I have to reboot (or the machine crashes)? Won't a block be lost?
The client is reporting the wrong time!
I see this R in the middle of my percentage bar - what does it mean?
But it just did two blocks with 'R'! How is that possible?
What does "Read partial block from another cpu/os/build. Marking entire block as unchecked." mean, and how can I fix it?

Crunch rate and performance:
Which processor does the client run the fastest on?
Crunchrate appears to go DOWN when I'm not at my computer!
Disable multimedia keyboard buttons to increase Client speed
Packets take too long to complete on my computer. They should be smaller!
Do you have any tips for achieving the best client speed?
Win32 GUI: Benchmarks run from a menu consume too much CPU time
Is overclocking good to do?
My client is much slower since I upgraded my OS (or motherboard/cpu)!
Hyperthreading gives me two processors, but why isn't client isn't twice as fast?
Why does a 64bit client perform better/worse than a 32bit client?

Porting the client, and common port/feature requests.
What platforms are supported
I want to port the client to my platform. Can I get the source?
Wouldn't a PVM, MOSIX, MPI, or Beowulf class distributed computer be faster?
What about a core for the CPUs in video accelerator cards?
Why not have auto-downloading, auto-updating, or plug-in based clients?

Other answers in this category:
Can you tell me a little more about what data is actually saved within packets?
I can't choose "Configure" or "Benchmark" in my windows client! What is going on?
What's the story with the hidden clients?
When will there be a new beta client released?

• Ensure that it is not running by starting the client with the '-shutdown' switch. eg 'dnetc -shutdown'. Under Unix, you may wish to kill(1) all instances of 'dnetc'.
• Windows: If it is installed as a service, uninstall it by running the client with the '-uninstall' switch. If you're not sure do it anyway.
• Unix: The client may have been 'installed' to start automatically (see Unix) and may require some steps to 'uninstall' it. Refer to the above mentioned URL for more information.
• If the client was installed in its own directory then simply delete that directory and all its contents.
• If the client is not in its own directory, you will have to find and delete the following files manually. They will probably all be in the same directory. There may also be log files in this directory.
  dnetc.*, buff-in.*, buff-out.*, rc5des.*, rc5desg.*
• Windows: If there is a dnetc.scr in the windows or windows/system directory delete that too.
• Unix: Maybe check the user's crontab if he scheduled the program to run at certain times.

Before configuring the system to launch the client on boot, please ensure that it can start normally.

Note: many clients provide some form of feedback on successful -install and -uninstall. To suppress those messages, use the -quiet switch, but make sure to specify it *before* the -[un]install switch (for example: dnetc -quiet -install), because the options that follow -install are the ones that the client is then 'installed' with (this feature is not available everywhere).

Special notes:
MacOS
OS/2
Windows (32bit)
Unix

Alternatively, if the MacOS FBA (faceless background application) version of the dnetc client was distributed with your MacOS download, then you may use that version. The FBA version completely lacks any user interface at all, and will not even be visible from within the Applications Menu.

Newer distributions (2.8012.466+) of the client for MacOS may include a client that runs as a system extension. This enables the client to be launched before the finder starts and run without a user interface.

Although services on Win9x and WinNT are dramatically different in terms of implementation, dnetc attempts to make the behavior between the two environments approximately equal.

In order to reduce its footprint and other overhead, the client runs with an implicit -quiet when started as service, so, even if it did not use the check-for-shell described above, you wouldn't see anything.

Explicitly unencrypting each of the individual files within the directory is not sufficient, since new files created in that directory by the client will inherit the encryption from the parent directory.

Configuring the service to login as me (instead of as LocalSystem) seemed to fix it, but the safer approach is to keep the distributed.net client in an unencrypted directory, where no parent directory is encrypted either.

This limitation will also be apparent if you ever try to encrypt your Windows directory itself, or the base "Documents and Settings" directory (that contains the profile directories for multiple users, not just yourself), or the root directory of a hard drive that contains things that multiple users or the system itself needs to access. Generally speaking, only sensitive documents should be encrypted, and not application directories, or entire hard drives.

Although not specific to NT service, be sure that the interface name that you've told the client to monitor is the correct interface name of your modem connection. However, typing the interface name incorrectly will prevent the client from detecting your modem connection when running as an NT Service or as an interactive process.

The quick and dirty way:

• On BSD systems (FreeBSD, OpenBSD, NetBSD, BSD/OS, MacOS X etc):
  simply add '/path/to/dnetc -quiet' to /etc/rc.local
• On SysV systems (UnixWare, Linux, Solaris etc):
  simply add '/path/to/dnetc -quiet' to /etc/rc.d/rc.local
  Note that this is not a good thing to do on SysV since the OS will simply kill the client when it shuts down (to be more precise, it will send a SIGTERM first, but a SIGKILL almost immediately after it).

The long way:

• On BSD systems, each application may have its own startup script. These are generally located in /usr/local/etc/rc.d/. A script to start the client could look something like this:

  #!/bin/sh
  if [ -x /path/to/dnetc ]; then
    /path/to/dnetc -quiet
    echo -n " dnetc"
  fi
  

  The client will be stopped with a SIGTERM when when the machine is shutdown or rebooted.
  

• SysV systems have a more complex init/shutdown sequence. Your OS probably has a man page for it. init(8) usually, 'apropos init' may show more.
  

  [2.8011-464 and above support -[un]install for Linux (SysV-style)]

  Create a file called '/etc[/rc.d]/init.d/dnetc' that looks like this:

      #!/bin/sh
      if [ -x /path/to/dnetc ]; then
         case "$1" in 
             *start)
                #make sure we're only running one client
                /path/to/dnetc -quiet -shutdown
                /path/to/dnetc -quiet
                echo "Started distributed.net client"
                ;;
             *stop)
                /path/to/dnetc -quiet -shutdown
                echo "Stopped distributed.net client"
                sleep 2
                ;;
             *)
                echo "Syntax: $0 [start|stop]"
                exit 1
                ;; 
         esac
      fi        
      exit 0
      

  Then create a symlink in each of the /etc[/rc.d]/rc?.d/ subdirectories as follows:
  

  For the 0, 1 and 6 runlevels (halt, single-user and reboot respectively):
  

      ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc0.d/K10dnetc
      ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc1.d/K10dnetc
      ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc6.d/K10dnetc
      

  For the 2, 3, 4 and 5 runlevels: (runlevels 7, 8 and 9 are also valid, but not many unix variants have them)

      ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc2.d/S90dnetc
      ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc3.d/S90dnetc
      ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc4.d/S90dnetc
      ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc5.d/S90dnetc
      

  On entering a new runlevel, init(8) will run the scripts in the /etc[/rc.d]/rc<runlevel>.d/ directory of the runlevel it is entering. 'K' scripts are 'kill' scripts, and will be run with the "stop" command. 'S' scripts are 'start' scripts, and will be run with "start".
  More on how scripts are processed may be found in your init(8) man page.

  According to the above described scheme then, the client will be started on entry into runlevel 2, 3, 4 or 5, and stopped on entry into any other runlevel.

Here it is. Distributed.net client is supposed to be in /home/dnetc and a user called 'dnetc' must exist on the system. The script launches dnetc as user 'dnetc' instead of 'root'. This is to controll the user's rights.

#!/bin/sh #Source function library. if [ -f /etc/init.d/functions ] ; then

   . /etc/init.d/functions

   . /etc/rc.d/init.d/functions

  exit 0

 echo -n "Starting Distributed.net client: "
        if [ -f /var/lock/subsys/dnetc ]; then
  failure
  else
   daemon --user=dnetc /home/dnetc/dnetc -quiet
   RETVAL=$?
          [ $RETVAL -eq 0 ] && touch /var/lock/subsys/dnetc || RETVAL=1
  fi
  echo
        return $RETVAL

 echo -n "Shutting down Distributed.net client: "
 killproc /home/dnetc/dnetc -TERM
  RETVAL=$?
  echo
         [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/dnetc
         return $RETVAL

 case "$1" in
   start)
        start
      ;;
   stop)
    stop
    ;;
   restart)
    stop
    start
    ;;
   status)
    status /home/dnetc/dnetc
    ;;
   *)
    echo "Syntax: $0 [start|stop|restart|status]"
    exit 1
    ;;
  esac

eg: dnetc --help

Although not recommended since it is then a 'static' reference, the output of -help can be redirected to a file on all OSs except those that don't support redirection (NetWare), or those that only have a GUI (MacOS, Win16).

On 32bit Windows, for instance, 'dnetc.com -help > dnetc.hlp.txt' will work just fine.

It is also possible to specify individual addresses of course, and has its own set of advantages and disadvantages: Specifying multiple addresses may become cumbersome and difficult to track, particularly if you are maintaining a large number of computers. On the other hand, specifying separate email addresses has the advantage of allowing the stats server to show you block count information that is specific for each machine you are running the client on.

The clients that cannot take advantage of multiple processors even when the OS supports it, do so because of library or compatibility issues. Clients that fall in this category are HP/UX, SunOS 3, and Linux/S390. Under such circumstances, run one instance of the client per processor.

• Novell ZenWorks
• Microsoft SMS
• Standard NetWare/WindowsNT login scripts
• Windows 2000 Microsoft Installer packages (*.MSI)

REM dnetc install
SET INSTALLDIR="%windir%\dnetc"
IF EXIST %INSTALLDIR%\dnetc.exe GOTO ENDOFSCRIPT
COPY \\server\sharename\dnetc.exe %INSTALLDIR%
COPY \\server\sharename\dnetc.ini %INSTALLDIR%
%INSTALLDIR%\dnetc.exe -quiet -install
%INSTALLDIR%\dnetc.exe -svcstart [1]
:ENDOFSCRIPT

You will likely want to use "start /wait dnetc.exe -quiet -shutdown" since 9x/ME will typically not wait for GUI processes to run and finish before moving onto the next line in your batch file.

Windows 2000, Windows XP, and Windows Me all come with Windows installer support out-of-the-box. Windows NT4, Windows 95, and Windows 98 systems can download and install the Windows Installer runtime from Microsoft (if it has not already been installed for some other program).

To determine if you already have Windows Installer support, Start/Run and type "msiexec". If you see a version number displayed, then you already have Windows Installer support installed.

When the MSI installer is run interactively it prompts for the participant's email address. It defaults to "rc5@distributed.net" if it cannot find another address from an existing dnetc.ini file. The default can be changed by editing the MSI Property called "DNETC_PARTICIPANT_ID".

Additionally, the default installation startup mode is normally to create a shortcut in the All Users' Startup folder. If you want to make the MSI installer default to installing the client as a service, you can change the MSI Property called "DNETC_STARTMODE" and changing it from "AllStartup" to "Service".

One common (and free) editor is the Microsoft "Orca" editor that comes with the Windows Installer SDK. Unfortunately you must install the entire Windows Installer SDK from http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ in order to get it. After you have installed that SDK, inside of the \Program Files\Microsoft SDK\bin\ directory there will be an ORCA.MSI file, which you can in turn install. Doing so will add an "Edit with Orca" context menu item when you right-click on any MSI file. Navigate to the "Property" table in the left-pane, and then find the Property value that you want to modify in the right-hand pane.

Other MSI installer development products (such as Wise for Windows Installer, or InstallShield for Windows Installer) include the ability to edit exiting MSI database files. For a list of some of the other utilities available (both commercial and non-commercial) visit http://www.installsite.org/

Windows Installer also includes an MSI automation interface that can be used to programatically modify MSI database files via COM programming. It is possible to write small scripts (such as in Visual Basic, VB Script, or even Perl) to use COM and modify Properties within a MSI database.

   msiexec /i dnetc486-win32-x86.msi /qn

You can also override Property values when you use the command-line technique if you do not want to bother with modifying or editing the MSI database:

   msiexec /i dnetc486-win32-x86.msi /qn DNETC_PARTICIPANT_ID="user@domain.com" DNETC_STARTMODE="Service"

You can also automatically uninstall the client (assuming it was installed with the same MSI database) with something like:

   msiexec /x dnetc486-win32-x86.msi /qn

It is highly recommended that you test deployment of the dnetc MSI to a small set of computers before widely deploying it on large networks, in order to verify that it installs cleanly and does not introduce any other problems. You can use organizational unit containers to "assign" the dnetc MSI to just a limited set of computers.

When using Group Policy software installation, the dnetc MSI should be "assigned to computers" (not "published to users" or "assigned to users"). This is because the client cannot be installed per-user. When software is assigned to a computer, it will be installed while the computer is sitting idle at the Windows login dialog screen.

You should be sure to edit the MSI Properties (mentioned above) so that the e-mail address of your choice will be used by the client. Otherwise the default address will be used by the client when it is installed.

For a large number of machines behind a firewall it may be simplest to run a personal proxy within the firewall through which all client machines will transfer keyblocks.

If you suspect that your computer is being blocked by a firewall, it can be helpful to see how your web browser is configured. If you can figure out how it manages to talk freely with the world then perhaps the same strategy can be used for the client. For instance, from within Netscape you can select "Options" / "Network Preferences" and see if it is configured to communicate through a firewall. Often, you can just take this information and plug it directly into the client and everything will work perfectly.

Virtually all operating systems support crontab or "at" events. Win9x systems can use the "Scheduled Tasks" feature.

Starting with build v2.8008-459 of the client, there is now a single unified Linux binary (for each processor architecture type), instead of separate ones for each architecture and library combination. The name resolution incompatibilities have been worked around by using "clever" dynamic symbol loading techniques, but this didn't work very well (problems ranged from segfaults to hanging threads to simply not-working).

So, from v2.8011-463 on, the client does not even bother trying to work around the insanity introduced by glibc, and instead pipes/parses the output of 'host'. If you find that your Linux client is still reporting an error during connection attempts, it's probably because you do not have the bind tools installed on your computer. Look for a "bind-tools" binary package in whichever packaging format is appropriate for your particular flavor of linux.

More recently, starting in v2.9008-490 the Linux client is now statically compiled with ucLibc (instead of glibc) and no longer has any dependencies on the "host" utility. The only requirement is that your /etc/resolv.conf be properly configured with valid nameservers.

$ dnetc -a 145.89.128.249

If they change the ip address, or that server goes down, the client will fail. So I have the client running in a detached screen. And I check the output from time to time.

[Ed: This solution is not recommended.]

You can also setup dist.net to run offline, and setup a cron job to grab the IP of the keyserver and update the cache hourly. You may have to adjust the grep/sed expressions depending on your local flavor.

#!/bin/bash
# script to start, stop, restart, or update cache for the dist.net client
# is dist.net client on?
distnetON=$(ps --no-headers -o %c -C dnetc)

function start() {
  # run dist.net client offline
  /usr/local/dist.net/dnetc -quiet -runoffline
  echo "Started distributed.net client"
}

function stop() {
  /usr/local/dist.net/dnetc -quiet -shutdown
  echo "Stopped distributed.net client"
  sleep 2
}

function update() {
  # ping the keyserver, grab the ip from the output, and update the caches
  /usr/local/dist.net/dnetc -quiet -update -a $(ping -n -c 1 us.v29.distributed.net | grep \( | sed -e 's/^PI.\+\.net (//g' -e 's/) fro.\+$//g')
}

if [ -x /usr/local/dist.net/dnetc ]; then
  case "$1" in
  start|restart)
    # make sure that there are no clients running
    if [ "$distnetON" = "dnetc" ]; then stop; fi
    # now start it up
    start
    ;;
  stop)
    if [ "$distnetON" = "dnetc" ]; then stop; fi
    ;;
  update)
    if [ -e /var/smoothwall/red/active ]; then update; fi
    ;;
  *)
    echo "Syntax: $0 [start|restart|update|stop]"
    exit 1
    ;;
  esac
fi
exit 0

#!/bin/bash
# cron.hourly script to update the dist.net clients key server IP address

# if dist.net client not running, then start it
if [ "$(ps --no-headers -o %c -C dnetc)" != "dnetc" ]; then
        #/usr/local/dist.net/dist.net start;
        echo "not running"
fi

# check if red interface is connected
if [ -e /var/smoothwall/red/active ]; then
        # update in/out caches
        /usr/local/dist.net/dist.net update

        # write to smoothwall log
        logger -t smoothwall "dist.net: cache updated"
fi
exit 0

Just put the dist.net file in the directory where your dist.net client is, and adjust the paths, and it should work.

1. Ensure buffers are full (fetch)
2. Stop the networked client.
3. MOVE the buff-in.* (look where you installed the client) to floppy.

1. Download the client and install it on the laptop.
2. Set a "Checkpoint file" on the laptop (for example, use ckpoint.cp)
3. Sneakernet the floppy to the laptop. (Physically move the disk between machines).
4. For each buff-in.* file on floppy...
   1. Stop the Laptop client.
   2. Run the Laptop client with the "-import" option and specify the filename of the buff-in.* from your floppy. This will merge the in-blocks from the floppy into your Laptop's existing buff-in, preserving the blocks it already contains.
   3. MOVE the matching buff-out.* from laptop to floppy.
5. Start the Laptop client.
6. Sneakernet the floppy to the networked machine.
7. flush buffers.
8. For each buff-out.* file on the floppy, run the network client with the "- import" option and specify the filename of the buff-out.* from the floppy.
9. flush buffers again.

You actually would send or be sent a complete buffer file.

Up-to-date instructions can be found by sending a blank email to:
   fetch@distributed.net and/or
   flush@distributed.net

Examples of supported file sharing mechanisms include Windows file-sharing (SMB/SAMBA), UNIX NFS, Netware server volumes, AppleShare, and others.

This is in fact one of the recommended ways if you have a small number of machines that are not directly connected to the Internet, but have at least one machine that is connected and can share a buffer file to the others.

However, if you have more than 20 or so machines, then you may want to consider running a personal proxy on the "Internet-connected" machine, and allow all of the other computers to retrieve blocks from the proxy.

To work around this, you can either disable checkpointing entirely, or set the checkpoint file to be saved to a path that is local (or at least different) for each machine.

The amount of work can be configured by specifying either one of the following for each contest:

a) number of workunits to buffer for that contest. Once you've determined how long it takes your computer to process a single workunit, you can approximate how many you will need to last the timeperiods when you are disconnected from the Internet. This value is set in the "Fetch work threshold" option in the client configuration.

b) number of hours to buffer for that contest. This will allow the client to do a quick-benchmark the that it can estimate how many workunits it will need, saving you the trouble of doing the above calculation yourself. This value is set in the "Fetch time threshold" option in the client configuration. (Note that you must be sure to set "Fetch work threshold" for that contest to "-1" for the "Fetch time threshold" to be obeyed).

"Dial-up Detection ONLY mode" will ensure that your client AUTOMATICALLY updates the total number of packets it has to process when you connect to the Internet. (That is, it will not ever trigger an autodial by itself--it will wait for you to establish an Internet connection.) At the same time, it also will automatically send back all completed data packets. This is all done without any intervention on your part

If you configure reasonable enough work thresholds that match your normal dialup usage behaviors, then the client will not usually need to make connections by itself because it will already have enough blocks.

• project: A long-term endevour in order to accomplish a specific, clearly defined goal. RC5, DES, OGR, CSC are all distributed.net projects. All distributed.net clients supports at least one project, and all recent clients are capable of processing data from multiple projects simultaneously.

• core: The code in a client that is responsible for processing the data associated with a project. Each project that a client supports may have multiple cores associated with it (each core is then optimized for a specific processor or processor family/group).

• iteration: An iteration is a generic term used to denote the smallest unit of work processed by a core. For crypto projects (RC5, DES, CSC) this is a key, for OGR it is a node.

• key: This is the smallest unit of measurement that can be checked by the client for cryptographic projects (RC5,DES,CSC). Each key represents one possibility of the solution. (for DES contests, each key actually represents two possibilities since each key and its opposite [complement] are automatically checked at the same time). Individual keys can be checked relatively quickly by your computer, usually several hundred thousand per second.

• node: This is the smallest unit that is individually checked by the client for OGR. A typical desktop computer may be able to check a million nodes per second. Each node represents a single golomb ruler possibility.

• stub: Stubs represent groups of OGR nodes that need to be checked. The number of nodes within a stub cannot be precisely determined in advance, ergo the amount of time needed to complete a given stub cannot be determined either. In general, stubs whose marks sum to a smaller total will take longer to check.

• stats-unit: a quantum of fixed size, used for stats and nowhere else.
  
  • For crypto-projects (RC5-56, RC5-64, DES, CSC) a stats-unit is 2²⁸ or 268,435,456 keys. The exception is RC5-72, where each stats-unit is 2³² or 4,294,967,296 keys.
  • For OGR a stats-unit is 1 billion nodes (one Gnode).

• packet: a discrete unit of work which will be processed. Clients send, recieve and crunch in terms of packets. A packet may be composed of any number of stats-units, including fractional portions thereof.
  • RC5-56, RC5-64, DES, and CSC packets have anything from 1*2²⁸ to 32*2²⁸ keys.
    (ie, 1 to 32 stats-units)
  • RC5-72 currently has the restriction that each packet can only contain exactly one stats-unit, or exactly 2³² keys.
  • An OGR packet has exactly one stub, and that stub may have any number of nodes.
    (ie, 0.01 to N.nn stats-units)

Obsolete, historical terms:

The first and second generation of clients ran only crypto-projects: RC5 and DES. These two projects were sponsored by RSA and had a winner (and the prospect of monetary award), and as such were called contests.

Since a computer is capable of processing many hundreds of thousands of RC5 and DES keys per second, counting in single keys quickly becomes onerous, and the very first generation of clients introduced the unit of 2²⁸ keys, as a handier unit of measure. These first generation clients worked solely with this number, both as the number of keys it sent/received/processed as well as the number of keys used to represent "effort", or the "unit of of work" done, and what was displayed on the stats server. Consequently, this number of keys came to be known as a work-unit.

The second generation of clients introduced the ability to send/receive/process many more than 2²⁸ keys at once. For the purpose of (backwards-compatibility and) statistics, the 2²⁸ key "unit of of work" retained its meaning, but the term used to represent the number of keys being sent/received/processed at once had to be changed. Since the number of keys being sent/received/processed continued to be a multiple of 2²⁸, the unit being sent/received/processed was called a "block of work-units", or in short, a block.

With the introduction of non-crypto projects such as OGR, the terms contest, work-unit and block had to be reconsidered. OGR neither had a winner, nor did it use keys, nor did it have a fixed number of iterations ('keys' in crypto-parlance) per "unit-of-work", nor could multiple "units-of-work" be combined into "blocks of work-units" for sending/receiving/processing. Indeed, for OGR, there was a tendency to revert to the older meanings, since a stub is a work-unit in the oldest sense of the term, both as a literal "unit of work" and as the unit that is sent/received/processed.

To overcome this confusion, more generic terms project, stats-unit and packet came to replace the older contest, work-unit and block respectively.

	First Generation Term	Second Generation Term	Current Term
endevour/undertaking	contest	contest	project
unit used by stats	work-unit	work-unit	stats-unit
unit sent/received/processed	work-unit	block	packet

However, old habits die hard, and the old and new terms are often used interchangeably. While not technically correct in the generic sense, the old terms are still perfectly valid for the crypto-contests, errr... crypto-projects. :)

Unless configured otherwise, the client only uses *idle* time (i.e. the cpu time that would go 'wasted' because no other task or application wanted it).

When you are watching CPU utilization (such as with Task Manager or "top"), your computer might not be running anything else that needs to consume a significant amount of CPU time, and consequently you see the dnetc client using 100%. If however you were to have another task running in the background that was using CPU time, you'd see the client automatically use that much less.

Each time slice, the OS temporarily stops whatever program is running and checks to see if there is any other program that needs to use the CPU. If any other program needs to run, the OS allows it to do so for a time slice. It then repeats the cycle, checking with all other programs that are currently running.

There is also a "priority" for every process in the system that is honored by the OS that allows it to give the opportunity to run more frequently to more important programs. Having a higher priority will mean that a program will have less delay between when it needs a time slice and when it actually gets to have a time slice. Consequently, having a lower priority will mean that a program must wait for higher priority programs to have had their chance to use time slices already.

The dnetc client runs at the "idle" priority, which is the lowest priority offered by the operating system, and will be lower than any other normal priority application. This ensures that all other running programs will have plenty of opportunities (tens to hundreds of chances per second) to have used your CPU. No other programs must need to have fully used it, before the OS will allow the dnetc client to run for a time slice.

Normally, the "Pause when running" should not be needed since the OS priority levels handles scheduling perfectly well, but a few users have extra sensitive concerns and have found this option useful.

The client's configuration includes a "load-work precedence" setting that allows you to select the load order (and optionally disable specific ones). However, this setting does not prevent the client from working on other available projects if it does not have any more "ready work" for any of your earlier priority projects.

Notice that the normal behavior of the client is to not automatically attempt to fetch more blocks (for any project) until blocks for all enabled-open projects have been depleted. Because of this, if you do not like the fact that your client is not working "solely" on the first project that is enabled and open, you can do any of the following:

• Disable all of the non-desirable projects (by going into the "Load-work precedence" and setting the other projects to "=0"). Note that if the projects left enabled are ever "closed" or "ended" by the server, your client will shutdown, since it has nothing to do. You will have to remember to manually re-enable another available project when that occurs to allow your client to resume working. For example: "rc5-72,ogr-p2=0"
• Make sure that your client never runs out of blocks for your preferred project. This can be done by any of the following:
  • Enable "fetch/flush all buffers if any in-buffer is empty" (mode 4) under "Additional Buffer-level Checking" so that your client will perform an update when the last block of the current project is loaded, instead of when the last block for all projects is loaded. This option is the preferred method of all of the following items listed below, since it does not cause your client to connect excessively to the server.
  • Enable "fetch/flush all buffers if any in-buffer is not full" (mode 1) under "Additional Buffer-Level checking" so that your client will always keep its buffers "topped off". This will cause a network connection after every block that is completed/loaded.
  • Manually trigger network updates before you run out of preferred project blocks. This of course requires your to manually perform this action.
  • If you have a dialup connection enable one of the "Dialup-link detection" modes (formerly called "lurk" and "lurk only") and go online more frequently than the time required to exhaust all of your preferred project blocks. This will cause a network connection after every block that is completed/loaded while your modem is connected. These modes are available under the "Dialup-Link detection" menu.

time: you can't and neither can the client. It's not possible to predict how much time it takes to do an OGR packet.

packets: But, if you were to count in completed packets rather than time, then all you'd need to do is ensure that the thresholds are equal, and over the long run client will do 50% OGR and 50% RC5 packets.
Obviously, if you wanted to crunch, say, 20% RC5 and 80% OGR, you'd simply set the OGR thresholds to be 4 times that of the RC5 threshold.

If you want to work on only one project see: My client is switching between projects instead of working only on my first choice

However, in the event that your computer crashes or you lose power and the client is not able to properly save its place. Blocks that have not been returned to the keyservers will eventually be redistributed. In order to accommodate slower clients and to minimize duplication of work there is a long period after which a keyblock is assigned, minimally 90 days. If we reach the end of the keyspace without finding the winning key, we will start back at the beginning and assign the unreturned blocks.

This checkpoint file will keep track of your work and update itself every few minutes. If your computer does crash (or you have to do a sudden reboot) the client can pick up almost right where it left off and not lose or discard a data packet.

From:             Nathaniel Cameron Begeman <nbegeman@engin.umich.edu>
Subject:          Speed table
Date sent:        Tue, 27 Nov 2001 03:05:59 -0500

The following is a selection of RC5 core/processor speeds on the 
various machines at my disposal. Unless otherwise specified, the 
core used is the one that was automatically selected.

The Clocks/key column is the number of processor cycles required 
to process one key. The keys/s/MHz column is the crunch rate per Mhz.

Processor     Clocks/key  keys/s/MHz 

 68000                          81 
 68010                          85 
 68020                         361 
 68030                         384 
 386/386SX        2040         490 
 386/386SX(SMC)  ~1350         740  (Latest self-modifying core. Estimate) 
 68040                         907 
 486/486SX        1020         980 
 Itanium (GCC 3)   980        1020
 486/486SX(SMC)    960        1040  (Latest self-modifying core) 
 Pentium           700        1430 
 P4                700        1430  (4 clock latency on rotate left!!!) 
 AMD K6/K6-2/K6-3  610        1640
 UltraSparc II     507        1980
 Pentium-MMX       485        2060 
 PowerPC 601       421        2375  (allitnil) 
 Celeron/PII/PIII  340        2940 
 68060                        3030 
 AMD K5            310        3220 
 PowerPC 603/604   296        3378  (lintilla) 
 Athlon            290        3450 
 PowerPC G4        110.25     9070  (AltiVec) 

In my situation, I noticed the distributed.net client running very slow. I ran wintop.exe, a windows Powertoy, which is freely available from Microsoft and also downloadable as a standalone utility from add-ons page, to determine what programs were using the processor. Surprisingly, the client was only getting 2-3% of the processor time and the keyboard program was using 95-98% of the idle time of the computer. Once multimedia buttons were disabled in windows control panel, the client increased it's speed dramatically.

For HP computers, go to control panel, select Keyboard and then deselect "Enable multimedia buttons and onscreen display" so Windows will not use processor time to continually check multimedia keys for presses.

However, it becomes increasingly less efficient for everybody as more and more people get faster machines too. The greater amount of network fetching and flushes translates directly to a greater amount of network bandwidth required by distributed.net's servers. Furthermore, as the number of total people participating in distributed.net grows, the total amount of required bandwidth increases as well. It might also be worthwhile to point out that your individual client actually has an overall reduction in work efficiency with smaller packets, since it must spend a greater amount of time switching between packets and restarting a new packet with different packet information.

Ideally we could distribute packets that are dynamically sized to exactly correspond to the speed of each machine, so that each packet would require exactly 24 hours or so. However, in the non-ideal world this is not quite as doable and so a compromise must be made and a size selected for consistency purposes. Just for illustrative purposes, in RC5/DES/CSC the "work unit" size was 2^28 keys (and packets could be be a multiple number of contiguous "work units"). In OGR-24, the "work unit" was selected to be the 5-stub. For OGR-25, since the total ruler length increased by one mark, the work unit size was also increased by one mark, yielding the 6-stub.

For future projects and contests, it is very likely that the work unit size will be selected such that a "typical" machine will process an "average" work unit will be completed in approximately 24 hours or so. Obviously, there is some amount of variability in the interpretation of "typical" and "average".

In the past, the primary argument for requiring a moderately small packet size was so that the amount of wasted work could be minimized if a computer crashed while processing a given work unit. However, since the original release of the distributed.net clients, the automatic "checkpointing" feature has been introduced, allowing no more than approximately 10 minutes of computational work to be lost. Although checkpointing is not enabled by default, if you feel that your machine might be unstable and wish to accept the minor performance penalty that checkpointing incurs, it can be easily enabled.

• Disable fancy screen savers.
  On Windows, the OpenGL screen savers are particularly CPU intensive. If you can't do without a "cool" screen saver on Windows, use the screen saver multiplexor included with the client which forces the screen saver of your choice to run at a lower priority.
• Try comparing all cores ('dnetc -bench' from the command line) and ensure that the client is really auto-selecting the fastest core. (If its not, please send a message to help@distributed.net to that effect)
• For contests like RC5-64, request larger work units. Smaller work units require the client to spend more time saving completed work and fetching new work, both to disk (when a single work unit is finished) and to the network (when the buffer is filled)
• Don't configure the client to fetch and flush after every work unit.
• If your machine frequently crashes or is powered down without warning, consider using the checkpoint feature. Though the checkpoint takes time away from crunching, it preserves the work already completed.
• Consider using a (personal) web proxy that blocks animated advertising on web pages.
• Don't use the machine for anything else. };8)

• close unused applications, because some (including MS-Word 8) might eat a significant amount of CPU power.

• Disable "processor cycling" in the advanced settings of the "Energy Saver" control panel (if this option exists on your machine). This option slows down the processor when the machine is left idle. Disabling it has doubled the key rate on a G4.
• When the machine is not in use, make the client the frontmost application, which gets the most CPU share.

• Disable "Power saving" features in the control panel
• Disable animations (sliding and fading menus, Active Desktop, icon animators, mouse-tracking animations)
• Minimize the client window. When minimized, the client does not need to update its window, and can run more efficiently.
• Watch out for applications that steal an inordinate amount of CPU time. Some applications written using a Windows Timer event can consume all available CPU, but at a higher priority than dnetc. Other applications can get into a "spin loop" retrying a dropped network connection or other unavailable resource.

Benchmarks running at (what may appear to be) realtime priority is a typical manifestation of the worthlessness of Windows priority levels and scheduling.

Its impossible to have an IDLE priority process and have responsive GUI and file/net I/O at the same time, so what the client does is boost the priority of the main thread (the one doing file/net I/O) and the GUI thread to the lowest thread priority that is greater than or equal to what other applications have (9 when in the foreground, 7 when in the background).

At some point in the distant past, and on a day when everybody at Redmond wasn't thinking very well, the Win32 designers decided that all of the IDLE priority class priority levels with the exception of the very highest would be lower than the above mentioned "9 or 7" (normal) priority level. And the very highest is almost twice that of normal priority. The priority table for IDLE priority class looks like this: 1, 2, 3, 4, 5, 6, 15. As you see, there is nothing between 6 and 15.

The reason the client has to use IDLE priority class is because its the only way to ensure that the user's "priority" setting does not cause a cruncher to have a thread priority >= 7, which would otherwise cause the whole system permanently be fighting for cpu time.

(Remember that even one miscomputed key within a block, that happened to contain the key we are looking for, can ruin the entire project and invalidate the work of the hundreds of thousands of other participants if an entire re-check must be done.)

Furthermore, because the distributed.net client fully utilizes your processor and keeps it continuously busy, your processor will generate more heat than it would if it were completely idle. For systems that are properly designed to incorporate sufficient cooling, this should not be a problem at all. However, for machines with inadequate or broken/failing fans this may cause a buildup of heat, causing the same malfunctioning that may occur in overclocking environments.

Even running the built-in "test" functionality within the client may not be sufficient to detect such occasional failures, since the failures may only occur after a sufficient amount of heat has already built up. It might be beneficial to run your client with disabled networking for a few hours (so that it will not transmit back any potentially bad blocks), and then quickly stop the client and activate its "test" function to see if that reveals any problems. However, although we try to be thorough in the "test", it may still not detect all occasional CPU malfunctionings due to heat stress.

In summary, we highly recommend not overclocking at all. However, if you feel you must, it is probably not best to overclock to the very verge of crash tolerence--one or two steps below your systems operational maximum might be a better choice. Either way, please be sure to have *more* than sufficient cooling.

Note that AMD processors generally, and the K6 series in particular have lower heat tolerance than, say, Intel processors, and have a tendancy to overheat even without overclocking. Numerous "bug" reports about the client causing the whole system to become unstable have been reported (See bug #200, #242, #1262, #1276, #1300,...), which is of course not the clients fault at all.

RC5-64 is a serious project that demands RELIABILITY, and it would be a good idea to run the processor at the speed it was designed to run.

If you do see any significant differences in client speed in a different OS, there is more likely just a misconfiguration in the slower OS that is causing it to be unable to utilize your processor correctly. For instance, it may be operating the processor in a reduced power APM mode, or you may have an incorrect/buggy hardware driver that is causing it to constantly poll that device, or there may be some stray process/screensaver that is just stealing processor cycles. You should investigate those causes first.

If you upgrade your hardware and find that your client is operating significant slower, when you were expecting it to go faster with your newer hardware, you should definitely check your hardware settings. This includes settings such as APM power management, clock rate, motherboard frequency, and cache enablement features.

With two processors (from the Operating System's perspective), it provides greater opportunity for a second thread blocking on the result of the first thread to already be "running" on the second "processor", reducing the OS overhead with identifying which thread to pick next and context-switching it in.

The dnetc client is computationally bound and the cruncher threads are not blocking on activities of the other, so it is probably not the intended type of application that would benefit from Hyperthreading. OGR crunching performance can improve with hyperthreading while RC5 performance typically suffers with it enabled.

Also keep in mind that when running in Hyperthread-enabled mode, the client is likely automatically detecting two processors and is able to run two cruncher threads. The combined speeds of the two threads are closer to the speed in non-Hyperthread mode. (The remaining difference can be attributed to the computational overhead of the Hyperthreading implementation.) Also note that when hyperthreading is enabled, interactions between other applications and the client can alter the performance of both.

In the case of RC5, which is a 32bit algorithm, a 64bit processor provides no real advantage, in fact it can be a slight disadvantage.

For OGR however, 64bit processors can substantially improve performance as fewer registers are needed to store the basic OGR data structure and thus fewer instructions are required to manipulate it.

On some platforms, X86 and AMD64, for example, different cores are required or desired for the 32bit and 64bit clients. These cores are usually optimized differently and thus have differing performance. Cores are occasionally modified and improved, which can result in performance differences arising between client versions. Further to these factors, the compiler or options used when building a client port may affect the core performance.

All of them :) Well, almost. Minimum requirements are a platform ...

• with at least a 32bit processor,
• with a reliable power supply (forget those handhelds, crunching takes power),
• with 750K of real (not VM) memory (as of Jan/2000),
• with some means of transferring work to/from a keyserver,
• supported by a decent c++ compiler
• with more than a handful of installations
• with someone to do the dirty work

The list of currently supported clients is on the the official client download page.

Clients (albeit cannot participate) can be built from the source available on the source download page.

The crunchers are designed for pure computation, they make no libc calls, and do not interact with any other part of the application. All that is left to a controlling thread which regularly polls the crunchers (which are also threads and so share address space with the controller) to check for "done, need more work" but thats about it.

In the long run, making the client cluster-aware is a tradeoff: On one hand you'd have the usability issue - being able to manage a single client, on the other hand you'd have some loss of efficiency due to the IPC overhead.

A general-purpose message-passing scheme may benefit distributed.net in the future but it isn't of any real value to the client for improving overall speed at the moment.

Client versions prior to v2.8014.468 were capable of being used on a MOSIX cluster. Subsequent client versions use shared memory which prevents migration on a MOSIX cluster. A separate client for Linux-x86/ELF using pthreads was made available as v2.9001.478 which inherently disabled the need for shared memory. Starting with client v2.9003-480, the generic client disables the use of shared memory when specifying the '-numcpu 0' setting on the command line.

A MOSIX cluster can then be used to run the distributed.net client by starting a seperate client for each cpu in the cluster and specifying the '-numcpu 0' command line option.

If implemented, such functionality would be optional and not enabled by default.

• The version of the client that last worked on the packet.
• The operating system that the client that last worked on the packet ran under.
• The processor family that that OS ran on.
• Partially completed packets also contain the core number that last worked on the packet.
• The distributed.net id (email address) of the client that last worked on the packet.
  Note: If you change the email address in the client, only those packets that have yet to be processed/completed will be effected. Previously completed work will retain the old address.

When a partially completed packet is loaded by the client, and the client version or OS or processor family or core-number do not match those of the client that previously worked on it, the packet is treated as if no previous work had been done at all (all work is reset).

What you are seeing is the client trying to make a connection to the internet to request more work, or return completed work. There are a few things that you can do.

• You can let the client finish the network activity (watch the client screen) and then proceed with benchmarking or configuring
• You can close the client and re-start it, or use the "Quick Commands" that are in the distributed.net programs folder.
• You can open a console window (aka "DOS" window on Win9x), and go to the same directory as the client. Type "dnetc -config" or "dnetc -benchmark" at the prompt.

You can also type "dnetc -help" to get a list of all the commands.

The hidden capabilities of the client are provided as a convenience to those who are authorized participants. Participants who run or install the distributed.net client on a computer without the permission of the administrator or owner are not permitted. When caught, such participants become ineligible to win any contests, and all past and future work submitted is hidden from stats.

If the participant belongs to a team, that team may suffer the same consequences. These consequences apply just as much to the person who sneaks dnetc onto a co-workers computer as to those who write "trojan-horse" applications to propagate the client across the internet.

If you believe your computer is running an unauthorized install of the distributed.net client, please e-mail help@distributed.net so we can fully enforce our policy and assist you with removal.

All clients (for platforms that support multiple tasks) support the -hide (synonymous with -quiet) option.

On UNIX-ish platforms this is approximately equivalent to launching the client with "nohup dnetc 2>&1 /dev/null &" (Though we highly recommend -hide instead of nohup, due to pipe and signal handling issues. Besides, the redirection prevents the client from warning you when it fails to start.)

To configure the client to run as a service, a) ensure that it can start normally, b) install it as a service with the -install command line switch. The client will then start automatically when you restart the machine.

My proxy's connection is frequently disconnected from the Internet and is always too busy trying to make outgoing server connection to handle connections from my clients. Why is it ignoring my clients?

How does offline mode work?

Why does my perproxy fail to connect?

I want my proxy to automatically make upstream server connections at only certain times of the day.

What about offline or sneaknet proxies?

Lurk/Lurkonly support for Linux in proxyper?

My firewall prevents the proxy from doing DNS lookups.

Answers related to capacity and capacity planning:
How many clients can a personal proxy handle concurrently?
How many blocks should the proxy hold?
My proxy only downloads 1000 stats units, but I need more.
My clients connect to my personal proxy but never fetch anything.

Answers related to logging and log statistics generators:
How does the personal proxy report email address, IP address, platform, OS, and client version information to the master keyserver?
I don't understand the timestampflags options and what combinations are available.
Can I get statistics from a public keyserver like I can for personal proxies?

Other answers in this category:
My newly installed perproxy won't serve blocks to my clients. What gives?
Can my clients share my personal proxies buffer files?
How can I run the proxy hidden or in the tray on Win9x?
Why is there no personal proxy for my operating system platform?
Automatically starting the proxyper at boot time (Linux)

If you have any other questions or difficulties using this proxy, you may send us a message

You might also try sending your message to proxyper@lists.distributed.net, which is a mailing list, and you must join it before sending a message to it. For information on subscribing to the proxyper mailing list, visit our discussion page.

Some users may also problems with reliable name server resolutions with other builds as well.

For both of these causes, you might want to try picking a keyserver and put its IP number into proxyper.ini instead of using a DNS name. For example:

[KeyServer]
ipaddress=206.109.6.80
port=2064

Instead, the recommended method of handling with such situations is to configure the proxy to run in "offline" mode and use the scheduling functionality of your Operating System to script events that will trigger the proxy to explicitly flush. On UNIX, you can force a flush (even in offline mode) by sending an "ALRM" signal to the proxy's process. There is currently no method of sending a similar event to Win32 proxies though this feature is planned for an upcoming version.

Alternatively, you may also consider scripting an event that will modify your proxy's ini file and change the connectivity mode from "online" to "offline" (or vice versa) at the appropriate times. You can then signal the proxy to reload its INI file on UNIX by sending it a "HUP" signal. When running as a Windows NT Service, you can restart the service with the "net stop" and "net start" commands.

If you have a proxy that is completely unable to make any sort of outward connections to the internet, there is still hope. Since the the proxy uses a different buffer format than the client, you cannot flush proxy buffers with another connected client. However, you can do the following:

1. temporarily shut down your regular personal proxy
2. MOVE your proxy's buffers to another machine that does have Internet connectivity.
3. temporarily start up a new personal proxy on that connected machine using those buffers, allowing it to fetch/flush as necessary.
4. after the connected machine has finished its network activity, shut down that personal proxy.
5. MOVE the connected proxy's buffer back onto your normal proxy machine.
6. restart your normal personal proxy.

Note that it is important that you MOVE your buffers between machines (or at least replace as you copy them). This is because there is no way to merge proxy buffers, so you want to be sure you do not accidentally end up with two non-empty in buffers, for example.

Additionally, it may be necessary to explicitly enable the "expertmode" on the connected proxy's ini file, so that you can specify buffer thresholds that exceed 1000 (since the connected proxy will not have any observable incoming block rate for it to "automatically" size the thresholds for you).

/bin/sleep 5
/usr/bin/killall -ALRM proxyper

Note that locking your proxy to a specific IP address may leave it vulnerable to keyserver failures or network connectivity problems that prevent you from reaching that specific IP address. Additionally, be aware that occasionally distributed.net needs to change the addresses of keyservers. Normally, distributed.net actively maintains the DNS entries in the rotating round-robin records (*.v27.distributed.net) so that only reachable, active servers are listed.

For example, if you included the following lines in your "hosts" file, then your machine will bypass trying to resolve "us.v27.distributed.net" via a DNS server and randomly pick one of the fake IP addresses listed (you should replace the IP addresses with real ones of current distributed.net keyservers):

10.0.0.1 us.v27.distributed.net
10.0.0.2 us.v27.distributed.net
10.0.0.3 us.v27.distributed.net
10.0.0.4 us.v27.distributed.net

After you set up your proxy and have allowed it to run for a couple of days, you should have a good idea of your overall average keyrate (and number of completed blocks) by simply observing the average keyrate reported by the proxy itself in its console output.

[rc5-64]
minkeysready=25000
maxkeysready=50000

Note that the proxy does not physically modify your ini file to reflect a different value if you specify a number greater than 1000 (it only interprets such values as being something else).

If the proxy is unable to allow you to surpass the 1000 stats unit limit normally, then it does not believe that your current rate would satisfy a higher block limit. If you see that your reported block rate displayed by the proxy fluctuates greatly (perhaps due to irregular spurts in which your clients flush large number of blocks), then consider either making your clients flush more frequently. You can also try adjusting the sliding average window to encompass a larger time period, over which your sustained rate might be more indicative of "typical" activity. The last resort is to disable the intelligence with the expert mode described below.

If you read the readme, you'll see the existence of an expert mode option that will disable the intelligence regarding the 1000 stats unit threshold. However, you should be cautious in using it since you will no longer be protected from the safeguards that the limit attempts to protect you against (unknowingly fetching more blocks than you actually require).

You should check your proxy to see why it is unable to fetch more "ready" blocks. It is usually because of a network configuration error that is preventing it from connecting to the keyservers.

Because of this, it may appear that the client is not ever fetching enough packets to satisfy the amount you have configured in the client configuration, but in actuality it has fetched the number of work units you've specified.

(Note that the personal proxy buffer thresholds have always been measured in terms of work units, not packets).

The timestampflags option was introduced in build 313 and allows you to customize the format in which the date and times are displayed within the on-screen console log, the on-disk console log, and in keyblock log files (simultaneously, not individually). The following text is what the proxyper readme lists for the definition of the values for this parameter.

Please note that that the timestampflags parameter is the combination of two flags (64 or 128) plus one of the exclusive mode options (1 or 2 or 3). The modes are not bitmasks, and as such only one may be picked at any time. That is why "3" is listed as a distinct option, and does not represent the combination of "1" with "2". As such, the following list is the actual enumeration of all valid combinations.

components	sum	description
1	1	Local time, 2 digit year
2	2	Local time, 4 digit year
3	3	Local time, no year
1+128	129	UTC time, 2 digit year
2+128	130	UTC time, 4 digit year
3+128	131	UTC time, no year
1+64+128	193	UTC time, with label, 2 digit year (old style mode)
2+64+128	194	UTC time, with label, 4 digit year
3+64+128	195	UTC time, with label, no year

It is highly recommended that all future log parsing utilities written by 3rd party developers be capable of parsing any of the timestamp formats. Note however, that the "64" flag does not affect log files, only screen display. Additionally, typically it will not be necessary to take timezone into account (just treat all parsed timestamps as being within the localtime zone and then do not display timezone/UTC labels in your output). As such, only 3 different date formats really need to be parsed (2 digit, 4 digit, and no year). Alternatively, if it is the intention that a 3rd party log parser specifically not support the alternate log formats, then the author of the tool should be sure to clearly indicate what timestamp format is recommended for proper use of his parser tool.

One way to kick the proxyper off is to set maxblocksdone to a small number, then go to a client and manually flush some blocks. This induces the proxyper to connect to a keyserver, whereupon it will fill its input buffer. Now restore maxblocksdone to your preferred setting and restart your proxy. All will be well from now on.

I use a utility called Hide-It to do this. It puts an icon in the system tray which you can right-click on to hide/unhide taskbar buttons and even your desktop icons. It can be set to auto-hide apps when they start. It's freeware and works on 95/98/NT. http://www.expocenter.com/hideit/

The platforms that we offer the personal proxy for is intentionally very limited, relative to the platforms that are supported for the client itself. As such, we provide platform support for the proxy on only the platforms that we feel have a significant enough popularity. Although this may seem harsh and arbitrary, there are many reasons for this:

• Deployment of the proxy does not need to be as widespread as the client: With the client, it is advantageous to have a client for every capable platform possible, since each additional machine adds more computational power to the network. With the proxy, even a large corporation or computer lab typically only requires a single well-placed proxy server to accomodate hundreds or even thousands of clients. It is therefore very exceptional that among that many (presumably non-homogeneous) machines, that there is no other machine that is running one of the platforms already currently supported for the proxy.
• The proxy needs to be held to a higher level of testing quality: Because proxy servers have the potential of invalidating or corrupting the work of hundreds or thousands of clients that are sitting behind them, it is necessary to have a high degree of testing by many different people to attempt to detect problems quickly. With less popularly used platforms, there will necessarily be a far fewer number of installations using that ported binary, and therefore a higher probability that a binary containing a platform-specific bug may go undiscovered for a long time before it is noticed.
• The proxy needs to be regularly maintained and ported: Also using the reasoning from above that a proxy server has the potential of invalidating a large number of clients, it is necessary for continually updated binaries be made available for all platforms being supported when a new build is made available. All of the popular platforms that are currently supported by the proxy are widely accessible to the proxy developers and can be easily and rapidly performed by any of several possible developers if needed. With less popular platforms, we can usually only obtain one volunteer and there has been a higher rate of unavailability/unreachability and a lower retension rate of being able to continue to maintain a port for the indefinite future.
• Platforms must have perceived longevity for the upcoming future: It is difficult to phase out support for a platform after it was supported once, since users will generally tend to continue to run a binary for their platform rather than stop using it, even if it has been announced that a specific platform will no longer be supported and should no longer be used, even when running obsolete versions might compromise the results of client data going through that server.
• The proxy codebase is also the foundation for the fullservers and keymaster: Since the same codebase is used as the basis for the primary servers within the distributed.net network, there is a higher requirement of maintaining high-performance code that can handle the millions of transactions per hour required of the primary servers. Because of this, there is less flexibility in allowing significant architecture redesigns to accomodate the esoteric requirements or differences exhibited by platforms that do not offer function interfaces that conform to the existing platforms supported.

If we become aware of new platforms that we do not currently support but offer the significant amount of popularity and widespread usage, we will be happy to provide official support for them at that time.

  #!/bin/sh
  if [ -x /path/to/proxyper ]; then
        case "$1" in
                *start)
                        if [ -f /path/to/rc5desproxy.pid ]; then
                                proxyper_pid=$(cat /path/to/rc5desproxy.pid )
                                kill -15 $proxyper_pid
                        fi
                        /path/to/proxyper -detach
                        echo "started distributed.net personal proxy"
                        ;;
                *stop)
                        if [ -f /path/to/rc5desproxy.pid ]; then
                                proxyper_pid=$(cat /path/to/rc5desproxy.pid )
                                kill -15 $proxyper_pid
                                sleep 2
                                echo "stopped distributed.net personal proxy"
                        fi
                        ;;
                *)
                        echo "Syntax: $0 [start|stop]"
                        exit 1
                        ;;
        esac
  fi
  exit 0

    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc0.d/K10proxyper
    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc1.d/K10proxyper
    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc6.d/K10proxyper
    

    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc2.d/S90proxyper
    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc3.d/S90proxyper
    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc4.d/S90proxyper
    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc5.d/S90proxyper
    

For recent versions of Redhat Linux, this is a more appropriate 
startup script.  Note that you can specify a user to "runas" with
the "runas" variable.

To install this:
1.  Add the script to /etc/rc.d/init.d/proxyper (edit the stuff that
    says "path/to" and "runas" - it should all be at the front of the file.
2.  chkconfig --add proxyper

This should automatically create the symlinks based on the comments at the 
beginning of the script.  They will be addeed with the right names in the 
right directories.

Check your installation with:

chkconfig --list proxyper.

Start the service with 

service proxyper start

The messages will look like the others that are issued by the startup scripts as well.

#!/bin/bash
#
# proxyper      This shell script takes care of starting and stopping
#               rc5des personal proxy.
#
# chkconfig: 2345 86 25
# description: This starts and stops the rc5des personal proxy
# processname: proxyper
# config: /path/to/proxyper
# pidfile: /path/to/proxyper.pid

proxyper="/path/to/proxyper"
pidfile="/path/to/proxyper.pid"
runas="nobody"


# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

# Source proxyper configureation.
if [ -f /etc/sysconfig/proxyper ] ; then
        . /etc/sysconfig/proxyper
fi

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

[ -x "$proxyper" ] || exit 0

RETVAL=0
prog="proxyper"

start() {
    # Start daemons.

    echo -n $"Starting $prog: "
    if [ -f "$pidfile" ]; then
        proxyper_pid=$(cat "$pidfile" )
        kill -15 $proxyper_pid
    fi
    daemon --user "$runas" "$proxyper" -detach
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
    return $RETVAL
}

stop() {
    # Stop daemons.
    echo -n $"Shutting down $prog: "
    killproc $prog
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog
    return $RETVAL
}

# See how we were called.
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        stop
        start
        RETVAL=$?
        ;;
  condrestart)
        if [ -f /var/lock/subsys/$prog ]; then
            stop
            start
            RETVAL=$?
        fi
        ;;
  status)
        status $prog
        RETVAL=$?
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart|condrestart|status}"
        exit 1
esac

exit $RETVAL

Answers in this category:
Where are the keyservers?
I want to run a keyserver, who should I contact?
How exactly does all this work?
Why are there connections from distributed.net servers to my machines? (or "why are your machines attacking/accessing my network?")
Can I get statistics from a public keyproxy like I can for personal proxies?
What type of hardware runs the keymaster?
What type of hardware runs the main website?

Note that there are special round-robin proxy keyservers set up for our participants operating in Japan, Europe, Asia and Australia. They are located at:

• Japan -- jp.v29.distributed.net
• Europe -- euro.v29.distributed.net
• Asia -- asia.v29.distributed.net
• Australia -- aussie.v29.distributed.net

For example: us80.v29.distributed.net, or aussie23.v29.distributed.net

There is another level of server that can optionally exist below the proxy keyservers. These are the personal proxy keyservers (or pproxies). The pproxies request standard blocks from the proxy keyservers and then turn around and hand them out to clients. Pproxies are typically used as a method of distributing blocks through firewalls. They are also maintained by some teams. All team members operate through a single pproxy so that the team can use the pproxy log files to generate team statistics independent of the main statistics. This helps to ease the load on the stats server and gives the team some freedom to pick what information they want to track and how they want it displayed.

What seems to be the problem?

Every now and then, people report a malicious attack originating from a distributed.net server onto their network/firewall/machines. They usually report that our machines are probing their network, backing this up with a snippet of their firewall log.

What these people are really seeing is a response from our server to a connection initiated by your own machines. Most traffic monitoring and data capture utilities only show the direction of data transmission, but not the direction in which the connection was established. The connection being seen was established outward from the client to our servers.

Our servers are servers for the distributed.net distributed computing network. The machines at your site have installed a client program that needs to connect to our servers every once in a while.

Technical details

For more info on our project, see http://www.distributed.net/. The mission statement for our project can be found at http://www.distributed.net/mission.php.

People download a small client program to process data, which they retrieve from our servernetwork.

The protocol consists of the client initiating a connection on port 2064, port 80 or port 23 (the client can choose), and our servers respond to that. That's why you'll see portnumber 2064 on our side and a high portnumber on your side. (The portnumber on your side will typically vary for each connection, due to the inherent nature of outward TCP/IP connections uses dynamically selected ports.) So, it's not our server that intrudes your network/firewall, but your machine that connects to our servers.

Why is this client running here in the first place?

Some user on your network downloaded the distributed.net client program and runs it. If this was done without authorization of the admins/owners of that machine, please read the following information:

The distributed.net client program lets your computer be a part of a big distributed computer system. It runs in idle time of that computer. Read more at http://www.distributed.net/.

However, it's not our intention that users install the program on a computer that they don't own or administrate. Our policy can be read at http://www.distributed.net/legal/policy.php. Also, please check our trojans page where you can read about trojan horses that will install our client on your machine. This page is located at http://www.distributed.net/trojans.php.

It is really a shame that some users do not comply with our policies while running the client. If these users find some interesting results for one of our projects, and they run the client on unauthorized computers, they will not get credit for them. That's all we can do.

The current keymaster hardware is:

• Dell PowerEdge 2550
• 2U rack mount
• Dual processor, Pentium III 927Mhz
• 1GB RAM
• 70GB SCSI RAID-5
• Operating system is FreeBSD 4.5
• Purchased 2001-05-09

• Rack-Mount 4U Case
• Asus P2B-LS motherboard. Intel Pentium II-400
• Cheetah 18Gb Drive
• 256Mb DIMM
• Operating System is FreeBSD
• Purchased 1999-07-15

• Operating system was Windows 98 and Windows 2000.
• Put into service 1997, taken out of service 1999-07.

• Dual Opteron, 4GB RAM
• 1U rack mount
• Supermicro H8DAR-T motherboard
• 4x250GB RAID10 on 3Ware 9500S Controller
• Operating System is FreeBSD 8.0
• Purchased 2007, Put into full service during summer 2010, still in service.

• Pentium III-450, PS2-LS Motherboard
• 768MB RAM, two 9GB SCSI drives
• 4U rack mount
• Operating system was FreeBSD 4.10
• Purchased 1999-10, Put into full service 2001-05, Major services migrated off during summer 2010, Still in service, Scheduled to be taken offline 2010-11? (In service for 9.5 years)

• AMD K6 300Mhz
• 196 MB RAM, 8GB IDE
• AT mini tower case
• Operating system was FreeBSD 2.2.8
• Put into service 1998-09, Taken out of primary service and made secondary mirror 2001-05, offline due to hardware failure in 2005-09. (In service for 7 years)

• Taken out of service 1998-09

Answers in this category:
What is the RC5-64 Project?
Were there other people trying to do this?

During the RC5-56 contest there were two other groups (Cyberian and Infinite Monkeys) competing against distributed.net (it was called the Bovine project back then).

However, the RC5-64 contest is a much tougher problem (256 times tougher to be exact). We are not aware of any other competing groups that took part in the challenge of breaking RC5-64. Cyberian did announce early in the contest they would also be mounting an effort but never did so.

Finally, there were several similar efforts which took part in the first Secret-Key Challenge contest which had to do with DES encryption instead of RC5. The largest of these were SolNET and DESCHALL. (The DESCHALL group went on to win that contest in June of 1997).

One collection of DES related links is at http://www.tcs.hut.fi/~helger/crypto/link/block/des.html

This collection includes pointers to the algorithms used by the d.net client (BrydDES and Kwan). One bitslicer not included in that list is from Andrew Meggs - the source to that in the d.net client source ( http://www.distributed.net/source/)

DES implementations are also often available in the many operating systems that come in source. For example OpenBSD http://www.openbsd.org/ and FreeBSD http://www.freebsd.org/. Solaris has made its 'secure download' source available too at http://www.sun.com/software/solaris/encryption/download.html

A bibliography on DES (and other block-cypher related) material is at http://www.ii.uib.no/~larsr/bc.html

For a general overview on crypto, I suggest you try and get the book "Applied Cryptography" by Bruce Schneier. You may also wish to review http://www.tcs.hut.fi/~helger/crypto/

Please visit our CSC page for more information on this project.

Answers in this category:
Is it really over?
Were there any other groups working on CSC too?

Our fourth victory was on 16 January 2000 when, shortly before 0630 UTC, we received the winning key (00438EF36FE3FC21 for you tech junkies) for the CSC contest from a Sparc in the United States after searching for 62 days. The secret message was:

  CS-Cipher a ete presente en mars 97 a 'Fast Software Encryption' (PARIS). Congratulations to the winner!

The Winner is Paul Ilardi, Grad student at the University of Rochester. Congratulations to Paul.

What are Optimal Golumb Rulers?

What would solving OGR actually be good for?

If Golomb Rulers up to 150 marks are already known, why are we doing this?

Is there a prize for winning OGR?

What is the total number of stubs/nodes in OGR-24 or OGR-25?

What is the most optimal ruler found by d.net so far?

Tell me about the total project percentage complete and Phase 1 and Phase 2?

Client and proxy answers in this category:
What minimum client and proxy versions are needed for OGR?
the personal proxy's completed count jumps by irregular amounts for completed stubs.
why is OGR disabled on my machine? (It runs OGR elsewhere.)
Why can't I get any OGR blocks sometimes?
How does the client search for OGRs?

Speed answers in this category:
Why do some stubs go faster than others? My stub OGR stub takes too long! My OGR stub has stopped progressing at 1 or 2%!
Why did I receive a very large/small OGR-25 stub?

My client is switching between projects instead of working only on my first choice
I'm confused about keys, stats units, nodes, stubs, packets, blocks, work units,...
Packets take too long to complete on my computer. They should be smaller!

http://members.aol.com/golomb20/intro.htm

^* The 'generic' OGR core in the distributed.net client is an adaptation of Mark Garry's work ("GARSP" stands for 'Garry's Adaptation of Rado's Searching Principles').

But you do get the chance to contribute however fractionally to the sum total of human knowledge, and may even get mentioned in the footnote of some obscure maths journal.

And it is good karma.

Update:

Actually, yes. Jonah Schulte is offering the "winner" 20 U.S. dollars. :) If there is more than one "winner" of OGR, Jonah will select one winner at random to receive the big cash prize.

As OGR is more of an "exhaustion of possibilities" as opposed to an attempt to find the correct key, Alex "froggie" Heighton is offering a genuine, english 1 shilling piece (note: not legal tender in the UK) to the last stub submitted.

NukeEmUp@ThePentagon.com has offered to wire UK£50 to the 'winner', or the equivalent in other major currencies.

neil@whatUseek.com will send you a $50.00 US check/cheque if you "win" OGR. He thinks this a small price to pay for reducing your chances of winning the RC5, and increasing his. ;-)

Hit1Hardhas offered to send a Fl 25,- guilders note to the "winner", "since we Dutch have the nicest money of the world. (its seen as "monopoly" money)"

Keep in mind that the number of nodes within a given stub has absolutely no relation to the "shortness" or "optimality" of the ruler that the project is looking for. The node count merely represents the number of golomb ruler possibilities that were checked within that stub's prefix, of which any single one has a chance of being a golomb ruler that is more optimal than what is currently known.

You may want to also check out: Tell me about the total project percentage complete and Phase 1 and Phase 2?

Computing the percentage complete depends on re-collating all of the completed stubs and accounting for the distribution of stubs that count against the secondary verification pass, and requires entirely reprocessing several hundreds of megabytes of compressed completion data. It also depends on whether you are attempting to compute the overall percentage complete, or just the percentage of phase 1 or phase 2 of the project.

While the projects were running, the percentage complete for OGR-24 and OGR-25 were available at:

  OGR-24 -- http://stats.distributed.net/projects.php?project_id=24

  OGR-25 -- http://stats.distributed.net/projects.php?project_id=25

Phase 2 for OGR-24 started on 16-May-2004, and was completed on 1-Nov-2004.
Phase 2 of OGR-25 started on 16-May-2004, and was completed on 28-Oct-2008.

OGRNG (ie: OGR-26 and beyond) are expected to on only require one phase, however there will still be "sub-phases".

Although we try to present the OGR progress as just two percentages (one for phase 1 and one for phase 2), it is actually a little more complex.

For OGR-24, there was a phase 1, and then two sub-phases in phase 2:

• Phase 1 (aka "OGR24 classic"): 5-diffs stubs (len <= 70) belong to the OGR contest. Completed!
• Phase 2 (aka "OGRp2-24" sub-phase 1): 4-diffs stubs (the client places the 6th mark at a position > 70). Stub len < 80. Total 1131772 stubs. Completed!
• Phase 2 (aka "OGRp2-24" sub-phase 2): 3-diffs stubs (the client places the 5th mark at a position >= 80). Total 95748 stubs. Completed!

Similarly for OGR-25, there was a phase 1, and then there are nine sub-phases in phase 2.

• Phase 1 (aka "OGR25 classic"): 6-diffs stubs (len <= 70) belong to the OGR contest. Completed!
• Phase 2 (aka "OGRp2-25" sub-phases 1 thru 5): 6-diffs stubs (70 < len <= 95). Extension to the OGR contest. Subdivided into five chunks for manageability:
  • 48979672 6-diffs stubs : 70 < stub-length <= 81 Completed!
  • 42196852 6-diffs stubs : 81 < stub-length <= 86 Completed!
  • 47775232 6-diffs stubs : 86 < stub-length <= 90 Completed!
  • 46417392 6-diffs stubs : 90 < stub-length <= 93 Completed!
  • 36267180 6-diffs stubs : 93 < stub-length <= 95 Completed!
  (Total : 221636328 6-diffs stubs.)
• Phase 2 (aka "OGRp2-25" sub-phases 6 thru 7): 5-diffs stubs (len < 112, the client places the 7th mark at a position > 95). Subdivided into two chunks for manageability:
  • 38361468 5-diffs stubs : 0 < stub-length <= 98 Completed!
  • 38106790 5-diffs stubs : 98 < stub-length <= 111 Completed!
  (Total : 76468258 5-diffs stubs.)
• Phase 2 (aka "OGRp2-25" sub-phase 8): 4-diffs stubs (len < 122, the client places the 6th mark at a position >= 112). Completed!
(Total : 6515212 4-diff stubs.)
• Phase 2 (aka "OGRp2-25" sub-phase 9): 3-diffs stubs (the client places the 5th mark at a position >= 122). Completed!
(Total : 237944 3-diffs stubs.)

The higher-diff stubs overlap with the smaller-diff stubs from later sub-phases, so there is less work (fewer average nodes per stub) left for the later sub-phases. This makes the overall project percentage for Phase 2 (which is measured in stubs not nodes) seem to progress more slowly in the early sub-phases, than the later sub-phases.

Additionally, each stub is distributed at least two times in order to get the necessary validation by two different computers.

For OGR-NG (supporting OGR-26 and up)

Client: Requires v2.9101.507 or later. These clients can connect to proxy versions lower than 343, but will not be able to send or receive OGR-NG packets.

For OGR "Classic" (project phase 1)

Client: Requires v2.9008-490 or later. These clients can connect to proxy versions lower than 341, but will not be able to send or receive OGRp2 packets.

[2000-02-14 23:56:33] ogr r=16/16, d=3/3, 63.3 Mnodes/sec, tot=19
[2000-02-14 23:57:37] ogr r=16/16, d=4/3, 75.1 Mnodes/sec, tot=22
[2000-02-14 23:58:35] ogr r=16/16, d=5/3, 91.2 Mnodes/sec, tot=26

the totalNotify count for OGR represents the upper 32-bit word of the total number OGR nodes completed.

For each of the (artificial) OGR stubs in question, there were 13.52 Gnodes (13.52*10^9). The upper 32-bit word of that is (13.52*10^9)/2^32=3.178, which is the origin of the factor that causes your "tot=" count to increment by 3.

The proxy actually keeps track of the full 64-bit word of the total number of nodes completed, but the "tot=" printed only reflects the upper 32-bit word of it.

The current OS and CPU combinations where this automatic disabling is currently effective (subject to change) are as follows:

• RISC OS/ARM: (if the client is not being preemptively tasked)
  all
• MacOS/68k
  all 680x0 processors
• MacOS/PPC:
  PPC601
• Windows16/x86:
  386-class, 486-class, 586-class (incl. Cx6x86 and K5)
• NetWare/x86:
  all

In non-preemptive environments, the client controls its run:yield quantum itself, that is, it runs for a limited, specific, number of keys/nodes (called the timeslice), then yields, then runs, then yields, and so on.

The timeslice is computed dynamically while the computer runs, and generally follows this formula: crunch_rate_per_second/yield_frequency ^(*), where yield_frequency is a semi-static value representing the minimum number of times per second that the client has to yield control for the machine to remain responsive, and crunch_rate_per_second is continuously calculated.

For OGR, which has significant overhead, the larger the timeslice (upto a limit), the more efficient the core is. To put it another way: at small timeslices, which is what would be in effect on slow machines, the core ends up spending more time in starting and stopping than it does in actually working.

Moreover, the time slice cannot be honored precisely, and under some circumstances, the OGR core could end up doing several hundred thousand more nodes than it was told to do. In less critical environments such as Win16 and MacOS such occasional "jerkiness" may be tolerable, and it is left to the user's discretion to disable OGR if they feel such behaviour is unacceptable. In mission critical environments such as NetWare however, any jerkiness may have disastrous consequences, and for NetWare, OGR is completely disabled.

^*: For all practical purposes, the formula mentioned above is sufficient, but there are some gotchas:
yield duration: if another task runs for a not insignificant amount of time, or the OS imposes a maximum "task" switch frequency to avoid scheduling the same task too often, then this "yield duration" is going to affect the crunch_rate_per_second part of the computation, and the timeslice will be lower.
timer resolution: The formula mentioned above implies that that the smallest run:yield quantum that can be computed accurately is equal to the resolution of the monotonic time source. Using longer timing periods and averaging the results makes it possible to increases the accuracy of the computation, but this can still be no better than half the timer's period. This means that if the clock's resolution was say, 100ms, then the client can yield (at best) only every 50ms.

# Best known OGR-10 is of length 55, so don't search past that
For A1 = 1 to 55-OGR[9] # OGR[9] is the length of the optimum 9-mark ruler
  For A2 = A1 to 55-OGR[8]
    For A3 = A2 to 55-OGR[7]
...
      For A10 = A9 to 55
        Does A1 thru A10 form an OGR? If so, we have a new best OGR!
      Next A10
...
    Next A3
  Next A2
Next A1

Of course, this is a highly simplistic view, and there are many tricks that can be used to narrow the search. One important thing to note is that as the outer loop variables get large, the amount of time spent in the inner loops decreases drastically.

For distributed.net, these for loops are split between the client and the master. The master will generate a stub of a ruler, such as '25/6-5-8-21-15-3'. This tells the client that it should work on a 25 mark ruler, with A1=6, A2=5, A3=8, A4=21, A5=15, and A6=3.

Part of what the master does when generating stubs is limit the size of the stub. If this was not done, the number of stubs (and thus the amount of data the master would have to track) would be far larger than it currently is. More important, if initial stub size wasn't limited, many stubs would be generated that would take minutes or even seconds for a client to search. This would create a unacceptably large load on the network.

Greg Hewgill has a page that describes distributed.net's OGR implimentation in a bit more detail.

In general, stubs that have a larger numbered marks in them are "easier" than those with purely smaller numbered marks. Additionally, the node count of a stub will generally vary quite predictably with the values of the first two marks of the stub. Graphs of the node count distributions based on the first two mark values can be found for OGR-24 at http://www.distributed.net/statistics/ogr/ There are also similar graphs for the old OGR-21 effort at http://www.hewgill.com/golomb/

Unfortunately, this is due to the large amount of uncertainty that the client has while evaluating stubs. During the evaluation process, the client will discover that certain portions of the stub do not need to be evaluated and will correspondingly skip over the rest of that portion. Due to this behavior, it is very difficult to provide a linearly progressing percentage bar.

Although we generally tried to intersperse these experimental OGR-25 stubs into the outgoing OGR-24 distribution to minimize giving too many to any single person, we've learned this might not have necessarily been the case.

In any case, since our intended benchmarking use of these experimental stubs is finished, if you see that your client is working on a "25/" stub that does not have exactly 6 values after the slash then you can feel free to discard your entire buff-in.ogr containing these experimental OGR-25 stubs, if you are too impatient and want to process normally sized stubs. (Proper-sized stubs that you accidentally discard along with those will be eventually recycled and reverifed more than once eventually, so it is not a serious concern in this case, though you should avoid intentionally discarding valid blocks whenever possible.)

Even though statistics credit can only be given for OGR-25 stubs with 6 marks, the processing resulting from the larger and smaller sized test stubs still represent valid search ranges within the stub space, and have comparable contribution towards the project's overall search as the equivalent number of proper-sized stubs. The results from those larger/smaller stubs will also be beneficial in providing second-pass verification against clients completing the corresponding group of stubs.

For more information about the project itself, please visit our project page devoted to it at http://www.distributed.net/rc5/

Generic answers in this category:
Why are you doing this?
What happens when the key is found?
How will I know if my computer found the key?
What about ITAR?
Why doesn't an FPU make my computer crack RC5-72 faster?
Why are PowerPC-based and (most) Intel-based computers so much faster than other platforms on RC5-72?

Specific RC5-72 answers in this category:
What are the server address and port changes with RC5-72?
Why is RC5-72 slower than RC5-64?
Why do I get "file is not in distributed.net format"?
What minimum client and proxy versions are needed for RC5-72?
Updated client/proxy binaries for my platform are not yet available
Why does the client select the wrong core? (or Why does the client select different cores each time?)

To do something with all this computing power
After finishing the RC5-56 and RC5-64 contests, it was a natural next step because the existing client code base could be very easily converted to run RC5-72. Instead of making a mad rush to push the next generation, general purpose clients out the door, we decided to make the small alterations necessary to allow the existing clients to participate in the 72-bit contest as soon as possible. Providing new client software quickly helped maintain the interest of our large number of volunteers by providing a task we could continue to work on as a group.

To prove that small-bitsize encryption is insufficient
A loosely organized group of people on the internet (us!) deciphered an encrypted message in their spare time. That might be sufficient reason for the governments, security firms, and others to rethink their current beliefs of what "safe" encryption bitsizes are. Decrypting progressively larger bitsizes can only strengthen that argument by pushing the boundaries of what key lengths are considered feasible.

To explore the feasibility of cooperative networked multiprocessing
It's fascinating to see how easy (and difficult) it has been to band together this many computers, with this many operating systems, in so many time zones and put them all to work on a common computing task.

Because it's fun
Perhaps in the same way that writing a tic-tac-toe program in sendmail.cf is fun to some people, it's been a rewarding diversion for everyone involved.

Because you can win money!
There is a 10,000 dollar (U.S.) prize for the winner of this contest. After winning the RC5-56 contest we gave $1,000 to the owner of the computer that actually found the winning key, we kept $1,000 for ourselves and we donated the remaining $8,000 to Project Gutenberg. The prize distribution for this contest will be similar, and everyone participating has a chance to vote on which nonprofit should receive the majority of the funds. You can read more about the prize money distribution on the stats site. Other monetary prizes were similarly awarded for the completion of RC5-64, CSC, DES-II-1, DES-II-2, and DES-III

To get to know more people
You'd be amazed at the number of people you can meet by participating in this project, especially if you hang out in the #distributed channel on IRC, or subscribe to the mailing lists.

To attract the opposite sex
Well, maybe it has, maybe it hasn't. You never know ;).

Using separate software we attempt to decrypt the entire message. If successful RSA is notified. After RSA verifies that the correct key has indeed been found press releases are issued by us and RSA and the check for the prize amount ($10,000 U.S.) is mailed to distributed.net. distributed.net then distributes the money as described earlier.

If your computer does find the winning key you will be notified by e-mail after the key has been verified by RSA. This is one reason why it is so important that you submit keys using a valid e-mail address!

ITAR is "International Traffic in Arms Regulations", a set of U.S. government regulations that, among other things, limit the strength of cryptographic algorithms implemented in software destined to be exported out of the United States. The ITAR regulations, as they apply to cryptography at least, are outrageous! Raising public awareness of this problem is one of the reasons the distributed.net network exists.

The RC5-72 project clients are NOT ILLEGAL to export. In short our software cannot be used to encrypt or decrypt other people's data. It works on only the first few bytes of a pre-encrypted message comparing the results to a bit of known (and fixed) plaintext ("The unknown message is:"). Therefore it doesn't fall under ITAR restrictions unlike general purpose crypto software such as PGP (Pretty Good Privacy, a popular encryption program available on the internet).

Currently none of the clients attempt to make use of FPUs and we believe any use of the FPU will result in slower clients rather than faster ones. At least one bright person has suggested this is not necessarily the case and indeed he may be right. If anyone can develop an RC5-72 core that takes advantage of the x86 FPU for an overall client speed boost we would be very interested in hearing from them! If you are interested in looking into it the x86 core code is available and can be downloaded from http://www.distributed.net/source/.

For whatever reason, the designers of the IA32 (32bit Intel x86) and the PowerPC architectures decided to implement the rotate function as a hardware instruction.

Many other CPUs do not have built-in hardware rotate instructions and must emulate the operation by (at the very least) two shifts and a logical OR. This handicap is why many non-32bit-Intel ^[1] and non-PowerPC computers run RC5 slower than one might expect based on real-world benchmarks. It is also the main reason why the RC5 client is a poor benchmark to use in determining the speed or performance of a particular CPU.

^[1] The IA32 architecture is that used by the Intel 80386, 80486, Pentium, Pentium Pro, Pentium II, Pentium III and Pentium 4 processors. The Pentium 4 has a slow, multi-cycle hardware rotate instruction up until the Prescott revision.

Beginning with the new version 2.9 clients, the DNS server addresses *.v29.distributed.net will be used for all resolved connections. This configuration allows us to gracefully upgrade our servers and also deprecate communications with most older clients by eventually deleting name resolution of the older round-robin (but that is not expected to occur without several months notice).

Although the port number 2064 was originally selected by distributed.net at the start of RC5-64 (port 2056 was used for RC5-56), it was decided that a new network port number should not be selected for the new project. Because we have carefully enhanced our network protocol in a backwards-compatible way, it is not necessary to utilize a new port number to allow the newer clients to be supported simultaneously. Additionally it was felt that continuing to utilize the same port number would reduce the number of firewall configuration changes that network administrators would have to endure when upgrading their machines.

RC5-72 is being started with a blocksize of 2^32 instead of 2^28. Initially we will only support 1 block per packet, but this will change in subsequent versions. Since each block is larger, it may appear that RC5-72 is much slower if you pay attention to only the amount of time required for each packet.

However, RC5-72 also requires new "cores" for all CPU architectures. In some cases, the old RC5-64 cores were easily retrofitted to accomodate the new bit-size, but this was not always possible. In other cases, completely new cores had to be written from scratch, particularly on x86 due to the limited number of registers. But by default, many of the initial RC5-72 client builds are compiled using a generic ANSI C core that is only optimized by the compiler until our porters are able to find updated assembly cores for their platform.

Of course the overall project will be "slower" than RC5-64, since the keyspace that must be searched for RC5-72 is 256 times larger. Since computers of faster and faster speeds are being produced each year, and the great number of excited participants on the Internet, we hope to complete this project with the same amount of success that we've had with prior projects.

If you have assembly optimization experience for your platform, you should consider looking at the public source code at http://www.distributed.net/source/ and submitting an updated core if you are able to produce code that is faster. Over the following weeks and months, we will periodically be releasing new client builds that incorporate additional speed improvements. Even with RC5-64, initial client versions were far slower than the eventual clients we had near the end, due to ever better optimizations that were developed over time--the same process will need to occur with RC5-72.

[Dec 02 11:03:07 UTC] Open failed for 'D:\Program Files\distributed.net\buf ...
                      File is not in distributed.net client format.

then you need to delete one or more of your buffer files. Version 2.9 of the client mandates a new file format and will refuse to read buffers that were created by an old version of the client.

If you have completed blocks in your old buffers, you should consider flushing them with an old client before deleting them (and before upgrading to the new client).

Client: Version 2.9001.477 is the lowest version that RC5-72 results will be accepted from. (Results from beta builds of v2.9000 will be discarded). All v2.9xxx clients require a minimum upstream proxy/server version of at least build 330.

Personal Proxy: Build 331 is the minimum recommended version for supporting v2.9xxx clients (though the beta proxyper of Build 330 will function). Proxy build 331 requires a minimum upsteam proxy/server version of at least build 331.

(See also Updated client/proxy binaries for my platform are not yet available)