For example, some projects may parse the file and store information in a database, others may just copy the file somewhere else. Next, the assimilator daemon processes the canonical result using project-specific code. This is repeated until a quorum of matching results is found or a limit on the number of instances is If the results don't agree, or if one of the results is not reported by its deadline, the server generates an additional instance of the job, and sends it to a third host. If the validator determines that at least some of the results are valid, it marks the work unit and the valid results as valid, users who returned legitimate results are granted credit for it, and a "canonical result" is chosen. The validator can have custom project-code to do fuzzy comparison between results, or it can perform a bitwise comparison. One popular method would be to compare the results against each other. When all the results from a workunit are completed and returned, the validator checks them. The feeder periodically fills empty "slots" in the shared-memory block after the scheduler has sent those results to a client. Instead, a feeder daemon loads tasks from the database and keeps them in a shared-memory block, which the scheduler reads. The scheduler doesn't get available results directly from the database. The scheduler CGI program handles requests from clients, receiving completed results and sending new work to compute. A project does not explicitly create results the server creates them automatically from workunits. ![]() A result describes an instance of a workunit, even if it hasn't been completed. Computations to be performed by clients are called workunits. The server consists of two CGI programs and (normally) five daemons, written in C++. work distribution based on host parameters (workunits requiring 512 MB of RAM, for example, will only be sent to hosts having at least that much RAM ).locality scheduling (sending workunits to computers that already have the necessary files and creating work on demand).workunit trickling (sending information to the server before the workunit completes).homogeneous redundancy (sending workunits only to computers of the same platform - for example: Win XP SP2 only).The validation process involves running all tasks on multiple contributor PCs and comparing the results.īOINC servers also provide these features: After uploading from the user's client to a science investigator's database, the backend server validates and analyzes the results. ![]() ![]() Scientific computations run on participants' computers. BOINC servers run on Linux-based computers and use Apache, PHP, and MySQL for their web and database systems. The server can run on one or many machines to allow BOINC to scale easily to projects of any size.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |