Navigation Bar

RC5-64: Project Bovine

FAQ Revision 28-Dec-1997 02:21 GMT -- most recent changes by Charles Hubbard
Copyright © 1997 DCTI, All Rights Reserved

Table of Contents

Background Information

Progress and Status

How to Participate

The Software

Technical Details and Miscellany

-------------------------------------------------------------

BACKGROUND INFORMATION

What is the Bovine RC5-64 Project?

The Bovine RC5-64 Project is a project of distributed.net. It was formed in March of 1997 to tackle contests associated with RSA Data Security, Inc.'s Secret Key Challenge. Through distributed.net the Bovine Project provides and maintains the software and network infrastructure required to distribute RC5-64 keyblocks to participating computers all over the world.

The Secret-Key Challenge consists of thirteen separate but similar contests. Having successfully completed the RC5-32/12/7 contest (RC5-56) in October of 1997, the Bovine Project is now concentrating its resources on tackling the RC5-32/12/8 contest (RC5-64). The task involves testing (at most) 2^64 (18,446,744,073,709,551,616) keys to find the one that properly decrypts the contest message. This is a monumental undertaking that will require an enormous amount of computing power to succeed. Bovine participants from all over the internet provide that power in the form of spare CPU cycles on their own personal computers. Together they have helped to make the Bovine Project the largest and most powerful distributed computer on Earth!

Why are you doing this?

There are probably as many reasons as there are participants. Here are a few popular ones.

To do something with all this computing power
After finishing the RC5-56 contest the RC5-64 contest was a natural next step because the existing client code base could be very easily converted to run RC5-64. 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 64 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 64-bit encryption is insufficient
A loosely organized group of people on the internet (us!) deciphered an RC5-56 encrypted message in their spare time. That might be sufficient reason for the U.S. government to rethink their current polices on encryption technology. Decrypting an RC5-64 encrypted message (256 times harder to do) can only strengthen that argument.

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. It has not yet been decided how the proceeds from the RC5-64 contest will be distributed but we expect it will be similar. Feel free to make suggestions on the mailing lists or in EFNet #distributed.

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 EFNet #distributed channel, or subscribe to the mailing lists.

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

Who is involved?

People of every background and technical skill level are participating in the effort. You don't need to be a skilled programmer or an expert at cryptography to take part in the fun. All you need is a computer that occasionally connects to the internet and a desire to take part in a large, internet distributed computing project! A quick scan of the participating teams shows a wide variety of businesses, organizations and individuals are working on the project right now. Maybe the more important question to ask is, who IS NOT involved! The success of this effort depends on getting as many people to participate as possible. Join us today and tell your friends!

Are there other people trying to do this?

During the RC5-56 contest there were two other groups (Cyberian and Infinite Monkeys) competing against Bovine. The RC5-64 contest is a much tougher problem (256 times tougher to be exact). It is unlikely that any new competing groups will take on the challenge. Cyberian did announce early in the contest they would also be mounting an effort but so far they have not. Whether or not they choose to take on the challenge sometime in the future remains to be seen. There is also a group at MIT that is checking RC5-64 keys using clients written in Java. They can't participate directly in the Bovine effort at this time because the Bovine client specifications have not been publicly released. However they are friendly to the Bovine cause and they have stated that they will combine their work with ours when the specs to the next generation Bovine client are released sometime early in 1998.

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

How did all this begin? Where is it going?

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, commonly referred to as version 3 (or just v3), is being designed. The v3 clients are modular and will support any number of different, challenge specific computing cores. The completion of the v3 clients and proxy network will make it possible for distributed.net to take part in a large number of distributed computing projects at the same time. Some projects currently under consideration can be found here.

Why all the cows?

You'd have to ask Jeff "Bovine" Lawson, the RC5 coordinator.

-------------------------------------------------------------

PROGRESS AND STATUS

Where can I get more information?

The main distributed.net web site can be found at http://www.distributed.net. Information concerning the RC5-64 project in particular can be found at http://www.distributed.net/rc5/ and, of course, in the FAQ you are currently reading. Additionally, we maintain a rather lively IRC channel (#distributed) on the EFNet IRC network. Many of the distributed.net principals can be found there and even when the topic of conversation is not RC5 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. If you would like to subscribe to any of the lists, send a message containing the text "subscribe [list name]" to majordomo@llamas.net and you will be able to participate in additional discussions relating to the RC5 effort. An archive of all of the mailing lists is also available online.
List Name Description
announce Official announcements and information regarding distributed.net in general. This is a moderated list.
rc5 Unmoderated discussion about the rc5 effort.
rc5-digest All traffic from the rc5 list, but in digest format. The main rc5 list is very busy so unless you are willing to contend with 50-100 new mail messages a day the rc5-digest list is probably a better choice.
proxyper Discussion concerning the operation of the personal proxy keyserver software.

Can you please explain the statistics?

A comprehensive set of statistics for the RC5-64 project can be found in the Bovine stats web pages. Here you can find the overall team summary as well as stats on teams and individuals. The stats pages are updated once per day at 0:00 GMT. There are several bits of information displayed on the project, team and individual stats summary pages.

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 GMT) and the keyrate corresponding to this number of blocks.

How can I contact the project organizers?

The best way is to hop on over to the #distributed channel on the EFNet IRC network and start making noise. If, however, you'd prefer more private communications, try one of the following email addresses.

-------------------------------------------------------------

HOW TO PARTICIPATE

What are you asking me to do?

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 (see the Client Speed page for more information about your particular computer).

What do I need to participate?

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

What shouldn't I use to participate?

You shouldn't run the client on any machine that you do not own or administrate. For instance, it is considered bad form to run the client on your ISP's servers without their knowledge or permission.

Where can I get the client software?

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

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

What happens when the key is found?

When a client finds a key that correctly deciphers the first few bytes of the message (the first part of the message is known to be the text "The unknown message is:") it sends an alert back to the Bovine organizers. 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 Bovine. Bovine then distributes the money as described earlier.

How will I know if my computer found the key?

Initially you won't. We've set the clients up intentionally so as not to alert the user if a candidate key is found. There are several reasons for this. First, we have gone to a lot of effort to make this project successful. We want to make sure that we maintain control over the winning key until RSA has been notified. Secondly, a lot of people running the clients don't want the client playing Yankee Doodle Dandy if it finds the key. They run the clients in their office, on there secretary's machines, etc. and aren't looking for a lot of attention. Finally, the clients only perform a partial message decryption and it is possible (although unlikely) for them to generate false positives. There is no need to get excited until the key has been verified.

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!

Does my machine need to be connected to the net all the time?

Absolutely not! The clients have the ability to fetch up to 1000 blocks at a time which should keep even fast computers busy for a while. If all these blocks get checked before the computer reconnects to the internet then the client will continue cracking randomly generated blocks until the network is available. This allows any machine, even one that is only online once every couple of days or so, to check keys continuously.

Is my modem OK or do I need to have a faster connection?

Any modem is just fine! You computer will only want to communicate when it needs to download new blocks or report the status of old ones. Depending on the buffer sizes you select 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) so even when moving a large number of blocks over a slow modem it doesn't take too long.

Will my old, slow computer really help?

The key to completing this challenge 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 386's and 486's 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 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.

Won't I get in trouble for trying to crack encryption?

There is nothing illegal, immoral, or dishonest about what we are trying to accomplish. This is a legitimate contest sponsored by a legitimate and respected organization ( RSA Data Security, Inc.). We are trying to decrypt an encoded phrase which has been released to the public specifically to test and evaluate the strength of the encryption method used.

Can you tell me more about teams?

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://rc5stats.distributed.net/ and select Register New Team in the blue area on the left. 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 SOFTWARE

What platforms are supported?

There are currently clients for
  • Amiga (68k and PPC)
  • Apple MacOS 7 & 8 (68k and PPC)
  • Apple Rhapsody (68k and x86)
  • BeOS (PPC)
  • Data General
  • IBM OS/2
  • Microsoft DOS
  • Microsoft Windows 3.1
  • Microsoft Windows 95
  • Microsoft Windows NT (x86)
  • Microsoft Windows NT (alpha)
  • Netware
  • QNX
  • RiscOS
  • Unix (AIX, various BSD's, HPUX, IRIX, Linux, MIPS, OSF/1, SCO, Sinux, Solaris, SunOS)

and possibly others as well. The official client download page can be found here. If you don't see a client for your particular platform request it! New platforms are being added all the time.

How do you use the client software?

Official documentation on the use of the clients can be found at http://www.distributed.net/FAQ/current-client.html.

What's the story with the hidden clients?

Sometimes circumstances arise where you need to run the client on a system yet keep it hidden from the user. For instance, sysadmins of large computer labs are typically in this situation. Here are some notes on how to do this with various systems.

MacOS
Coming soon.

Microsoft Windows 3.1 and 95
Run the standard GUI client. From the Client Configuration dialog box choose the Startup tab and check both checkbox options ("Automatically launch client as a startup service" and "Run hidden and without system tray icon"). The options do not take affect until the system is rebooted. The client comes with a utility called guictrl.exe that will allow you to control it when it is hidden.

Microsoft Windows NT
There is an NT service version of the client now. Please read the document that comes with the distribution for more information.

OS/2
Just minimize the client. By default OS/2 hides applications. The client will still show up in the task list however. If you do not want it showing up, type detach rc5v2.

Unix
Typically the unix clients can be run in the background with a command similar to: nohup ./rc5v2 > /dev/null &. This will pipe the output of the client, normally destined for the screen (stdout), to the special device /dev/null, where it will essentially be thrown away. The ampersand operator (&) tells the shell to launch the program and then run it in the background. Using nohup will ensure the client does not exit when you log out.

If you need more information, consult the Online documentation, or read the documentation that come with the client distribution.

Why do I keep getting network errors?

The most common reason is because you are located behind a firewall and the client can't get directly out to the internet. There are work arounds as described in the next section. Intermittent network errors can also occur due to poor conditions on your LAN, poor phone lines, or heavy traffic on the internet itself. There have been some problems with earlier versions of the client being overly sensitive to response times. These problems have been mostly resolved.

What if I am behind a firewall?

Many of the clients have been coded to operate through a standard SOCKS proxy firewall. Additionally, if you live behind a port filter, most (if not all) of the keyservers will communicate on port 23 (telnet). 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 RC5 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 RC5-64 client and everything will work perfectly.

I have a multiprocessor machine. How can I get the client to use all of the CPUs?

Most (but not all) of the clients will take advantage of multiple processors. By default only one CPU will be used. This can be changed from the client's configuration menu.

Where are the keyservers?

Most clients should use the default keyserver rc5proxy.distributed.net. This is a round-robin DNS which will grab a proxy address at random. If DNS is a problem, it is possible to point your client at a specific keyserver. The available keyservers can be found on the Proxy Network Status page.

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

  • Europe -- rc5europroxy.distributed.net
  • Asia -- rc5asiaproxy.distributed.net
  • Australia -- rc5aussieproxy.distributed.net
You should use these if you live in the appropriate region and are having problems contacting the North American servers.

Can I share the buffer files across a network?

Yes! The clients are designed for this and the file locking that exists in network file systems will prevent multiple clients from updating a buffer file at the same time.

I want to run the client on several computers from a shared network drive. How do I specify separate configurations for each system?

You have a couple of options. By default the client looks for an .ini file (where client configuration information is stored) with the same name as the client. So for instance if your client is called rc5v2-1 it will look for configuration information in a file called rc5v2-1.ini. One solution then would be to create several copies of the client, each with a different name; one for each of the required configurations. Another option is to set the RC5INI environment variable during each computer's start up sequence. The client will preferentially use configuration information stored in the configuration file pointed to by RC5INI. In this way you only need one copy of the client software but you can have several different .ini files, one for each configuration that you need.

I want to run a keyserver, who should I contact?

Currently, there is no need for additional keyservers, although we certainly appreciate your enthusiasm. If you REALLY want to run a keyserver, recruit enough people such that we need to implement more servers to handle the load!

What About ITAR?

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

The RC5-64 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). More information on ITAR can be found here.

OK, I'm running the client software. Now what?

Welcome to the Bovine RC5-64 Project! We are happy to have you on board. While your computer is busy testing keys there are a several things you might want to do. First, visit the Bovine stats pages. They will let you monitor your individual progress, see how the project is progressing as a whole, and even join a team if you so choose. Also check the Client Download Page from time to time. New client upgrades are released all the time which fix bugs, add features and are frequently faster. It usually pays to run the most current version for your platform. Finally, if you want to stay on top of what's new you might consider joining one of the mailing lists or visiting the EFNet IRC channel (#distributed).

As we've said before RC5-64 is an enormous task! Our success depends on your participation. We need all the help we can get so tell your friends, your family and your co-workers! We really appreciate your contribution.

-------------------------------------------------------------

TECHNICAL DETAILS AND MISCELLANY

How exactly does all this work?

The Bovine RC5-64 Project is built around a pyramid architecture of keyservers and clients. At the top is the master keyserver. It keeps track of what keyblocks have been sent out to be checked, which blocks have been checked and returned and which blocks remain to be checked. Below the master keyserver are the main Bovine proxy keyservers. They serve as intermediaries between the clients and the master keyserver. The proxy keyservers request large blocks of keys from the master keyserver (what are called superblocks). >From these they extract the much smaller standard keyblocks (2^28 keys per block) and send them to the clients. Clients return checked keyblocks to the proxy keyservers which in turn send them on to the master keyserver. In this way many keyservers are available to distribute keyblocks without the risk that the same block might be handed out twice. The use of proxy keyservers together with the round-robin DNS proxy assignments also provides a certain amount of fault tolerance. If a given proxy keyserver fails the clients will automatically switch to another one with no interruption of service.

There is another level of server that can optionally exist below the proxy keyservers. These are the personal proxy keyservers (or pproxies). Rather than dealing in superblocks the pproxies request standard blocks from the Bovine 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 Bovine statistics. This helps to ease the load on the Bovine stats server and gives the team some freedom to pick what information they want to track and how they want it displayed.

What if my computer starts checking a block and I have to reboot? Won't that block be lost?

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.

My client just said "So take this wine, and drink with me." What's up with that?

One of the features of the keyservers is that the operator or keymaster operator can set a custom message which is displayed to clients as they connect. In the event of an emergency or important event, this feature could theoretically be used as a news bulletin, but while things are running smoothly it's been up to the keyserver operator to set this message. While most of dbaker's proxy messages (like the one above) could be viewed as a number of strange things, they're typically just song lyrics taken out of context.

How come the client is reporting the wrong time? I've checked the clock in my computer and it's right.

The time reported by the clients is based on your computer's internal clock however it is converted to and reported in GMT (Greenwich Mean Time). This makes comparing logs and updating the stats simpler.

I want to port the client to my platform. Can I get the source?

The source code and protocol of the current crop of clients is under limited distribution, but portions of it are available for download at the source download page. The project organizers certainly encourage cross-platform development and porting but this is being weighed against the potential for sabotage in the decision to release the code. Please contact one of the organizers to discuss the possibility of obtaining the source or to get a port for your platform.

The next generation of clients (commonly referred to as v3), currently being designed, will be based on an open specification which will use some combination of encryption and signature authentication to help reduce the possibility that the code can be used maliciously against the effort. The spec and the source code for the v3 clients will be freely available to anyone who wants it.

How come the DESCHALL clients were so much faster? Aren't the Bovine clients optimized?

Anyone reading this document that participated in the DESCHALL effort, may remember that the DES clients performed faster on some computers than the RC5 client does. That's because the DES algorithm uses simpler mathematics and is therefore faster to process than the more complicated RC5 equivalent. The Bovine RC5 clients are optimized, just as their DESCHALL counterparts were. The speed difference is due to the mathematics involved, not the software.

Why are Intel and PowerPC computers so much faster than other platforms?

Integral to the mathematics of the RC5 algorithm are 32-bit rotate operations. For whatever reason, the designers of the 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-Intel 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.

Why are the Cyrix and AMD chips faster than my Intel Pentium?

The Cyrix and AMD/Nextgen designers worked hard to increase the efficiency of their integer math components since integer math forms the basis for so much of the computing that goes on in the real world. As it happens RC5 uses strictly integer operations so it enjoys an added boost when running on these processors.

Why isn't my computer with an FPU faster than my computer without one?

RC5 involves a large number of integer additions, rotates and XORs. It doesn't require floating point calculations and won't, in general, benefit from them. There has been quite a lot of recent discussion on whether or not it might be possible to boost keyrates (on x86 architectures at least) by taking advantage of the fact that there are separate pipelines for integer and floating point instructions. (We leave it to the reader to figure out how to do floating-point XORs and rotates!)

Currently none of the Bovine 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-64 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://altern.com/rguyom/.

How about a PVM or Beowulf class distributed computer? Wouldn't they be faster?

Actually, no. Certainly a Beowulf (or Hyglac or Loki) class of distributed computer is going to be faster at RC5 than a single processor system but keep in mind that Bovine is a network distributed computer in its own right. Certainly it is not (yet) as versatile as a Beowulf system but given the task at hand the Bovine system is certainly as fast. Beowulf systems exhibit a couple of attributes that are lacking in the Bovine system. One of these is very fast inter-node network communication. This is not a useful advantage when it comes to the RC5-64 project as evidenced by the fact that Bovine nodes (clients) can run independently for days and only need to transmit small amounts of data when they do communicate. Beowulf systems also make use of a general-purpose message passing and control architecture that makes them more versatile in that they can easily be reprogrammed for any number of different problems. Although the Bovine interface is geared specifically toward the RC5-64 problem, RC5-64 is the problem at hand. A general-purpose message-passing scheme may benefit distributed.net in the future but it isn't of any real value to the RC5-64 Project.

Of course none of this is to say that a Beowulf class of parallel computer wouldn't work well at RC5-64. If you happen to have access to one add it to the effort! We'd appreciate the support!

I have a networked computer already participating, I have another computer that is not networked at this time, but would like to run the client on it to. How do I do this?

Directions for "SneakerNetting"

For Ease of directions, Laptop is the offline/non networked machine.
This also assumes you're using a M$ OS. The theory is the same though for all platforms.


Download the client and install it on the laptop.
Set a "Checkpoint file" on the laptop (for example, use ckpoint.cp)
(beware, the client will only accept 1000 total blocks)


Stop the Networked client.
Use the networked client to fetch a fresh buff-in.rc5.
MOVE the buff-in.rc5 to floppy.
Start the Networked Client again.
Sneakernet the floppy to the laptop.
Stop the Laptop client.
Copy the buff-in.rc5 from floppy to laptop checkpoint file.
(cp a:\buff-in.rc5 c:\dnet\ckpoint.cp)
MOVE buff-out.rc5 from laptop to floppy.
Start the Laptop client.
(It will import the ckpoint.cp into it's buff-in)
Sneakernet the floppy to the networked machine.
Stop the Networked client.
Flush the Networked client.
MOVE the buff-out.rc5 from floppy to networked machine.
Start the Networked client
Repeat.

The Next Projects

What happens when RC5 is over?

The Next Projects

There is a page dedicated to future projects currently under consideration. You can find it at: http://www.distributed.net/projects.html.

-------------------------------

Home - History Timeline - Mission - How To Help - Projects - Statistics
Research - Q/A - Mail Lists - Press Room - Credits - Legal
© Copyright distributed.net 1997, 1998, 1999 - All rights reserved
Last modified: Mar 31, 1999