BOINC is intended to accommodate participant hosts with a wide range of operating systems and hardware architectures. @@ -25,7 +25,7 @@ The combinatorial explosion of versions and architectures should be excluded from the internals of BOINC. -Design +
A platform is a compilation target. A set of platforms is maintained in the BOINC database of each project. @@ -51,7 +51,7 @@ Examples might include: The name of a platform should specify a particular version (e.g. of an OS) only if it uses features new to that version. For example, the platform sparc_solaris2.8 should apply -ONLY to SPARC machines running Solaris 2.8 or greater. +to SPARC machines running Solaris 2.8 or greater.
For simplicity, platforms are assumed to be mutually exclusive: @@ -70,46 +70,60 @@ Application developers will have to create versions for both 2.6 and 2.7, even if they're identical.
-Handling architectural diversity +
BOINC allows applications to exploit specific architectures, -but shifts the burden of recognizing the the architecture -to the application developer. +but places the burden of recognizing the architecture +on the application developer.
In other words, if you want to make a version of your application that can use the AMD 3DNow instruction set, don't create a new windows_amd_3dnow platform. Instead, make a version for the windows_intelx86 platform -that recognizes when it's running a a 3DNow machine, +that recognizes when it's running on a 3DNow machine, and branches to the appropriate code. +
-It is, however, desirable to report architecture back to the -BOINC server. -This makes it possible, for example, to report average or total -performance statistics for 3DNow hosts constrasted -with other Intel-compatible hosts. -This is done using the boinc_architecture() +
+BOINC collects architecture details about each completed result +to allow detailed statistical breakdowns. + +
+First, the core client attempts to find +the CPU vendor, the CPU model, +the OS name, and the OS version. +These are stored in the host record. + +
+Second, applications that recognize even more specific +architecure information can pass it back to the core client +using the boinc_architecture() function from the BOINC API. This passes a string (project-specific, but typically in XML) to the core client, which records it in the architecture_xml field of the result database record. For example, the application might pass a description like
- < +<has_3dnow_instructions/> +<graphics_board>ATI Rage 64MB+This makes it possible, for example, to report average or total +performance statistics for 3DNow hosts constrasted +with other Intel-compatible hosts. -Avoiding platform anarchy +
Each BOINC project is free to create its own platforms. -To avoid anarchy, however, +To avoid anarchy, however, we recommend that +platform creation and naming be coordinated by a single group +(currently the SETI@home project at UCB). -Tools -Each +
Platforms are maintained in the platform table in the BOINC DB, and can be created using the add utility. - -