Summary

  • Collection servers introduced in 2004 gave completed work an alternative destination when its original server could not be reached.
  • A June 2009 outage report shows the maintenance behind the arrangement: spare reception needed working software, capacity and people.

On 16 June 2009, Vijay Pande had an unromantic update for the people donating computer time to Folding@home. One GPU server had crashed so badly that it could no longer find its root partition. Two others had gone down under heavy load and had been brought back. At the receiving end of a grand scientific collaboration, somebody was trying a rescue disk. Pande's status report is admirably short on grandeur.

The donors had a practical interest in that repair. Their computers could finish a calculation and still need somewhere to deliver it. A finished parcel sitting at the sender's door is a peculiar form of generosity.

Folding@home began in October 2000 in Pande's lab at Stanford University, according to the project timeline. Volunteers installed software that obtained small portions of molecular simulation work, ran them and returned the results. The contribution was computing time on a machine whose owner could switch it off, change its settings or leave the project.

A second place to hand it in

The project's 2009 architecture paper identifies a useful addition made in 2004: collection servers, introduced with version 5.0 of the client. Ordinarily, a result went back to the work server that had supplied the task. If that machine was unreachable, a designated collection server could receive it instead.

That receiver checked the work against records of issued tasks. Accepted work received credit and waited to be forwarded when its original server returned. Meanwhile, the volunteer's client could ask a live work server for another assignment. The failed machine no longer had to hold the donor's next contribution hostage.

There was a benefit for the repair crew too. When the original server came back, it would face fewer clients still waiting to return their old work. Otherwise, the reward for restoring a server could be a queue large enough to knock it over again. Reliability has a sense of humour; administrators rarely enjoy the joke.

The donor also wants a receipt

The same paper describes volunteers with metered connections, modems and preferences about CPU use. It describes points awarded to users and teams, and volunteers helping others in the forums. These details belong together. The participant supplied a machine and accepted inconvenience; visible credit made the contribution legible.

The collection server therefore handled both a research result and a social obligation. Taking delivery allowed work to move onward, and accounting gave the donor a record of having contributed. A recruitment message asking for spare computing time quietly created a receiving department.

Pande's June 2009 note shows that department under strain. Staff were implementing new infrastructure alongside the old, with improved collection-server operation among the expected benefits. The rollout was beginning; the failures were slowing it down. A backup destination still needed maintenance.

The architecture paper's conclusion was equally plain: the backend had become the limit on adding more clients. Handling, storing and processing incoming results demanded resources of its own. The volunteers could lend more computers. Somebody still had to answer the door.