The computers available to a public-resource computing project have a wide range of operating systems and hardware architectures. For example, they may run many versions of Windows (95, 98, ME, 2000, XP) on many processors variants (486, Pentium, AMD). Hosts may have multiple processors and/or graphics coprocessors.
BOINC addresses the following goals:
A platform is a compilation target. A set of platforms is maintained in the BOINC database of each project. Each platform has a name and a description of the range of architectures it can handle. Each BOINC program (core client and application) is linked to a platform.
At the minimum, a platform is a combination of a CPU architecture and an operating system. Examples might include: "; list_start(); list_heading("name", "description"); list_item("windows_intelx86", "Microsoft Windows (95 or later) running on an Intel x86-compatible processor"); list_item("linux_x86", "Linux running on an Intel x86-compatible processor"); list_item("macos_ppc", "Mac OS 9.0 or later running on Motorola PowerPC"); list_item("sparc_solaris", "Solaris 2.1 or later running on a SPARC-compatible processor"); list_end(); echo"
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 to SPARC machines running Solaris 2.8 or greater.
For simplicity, platforms are assumed to be mutually exclusive: i.e. an application for platform X is not assumed to work on a host running core client platform Y if X ≠ Y. The BOINC scheduling server will send work to a host only if there is an application version for the same platform.
There should be as few platforms as possible. For example, suppose that there are both Solaris2.6 and Solaris2.7 platforms. Then any host running the Solaris2.6 core client will only be able to run Solaris2.6 applications. Application developers will have to create versions for both 2.6 and 2.7, even if they're identical.
BOINC allows applications to exploit specific architectures, but places the burden of recognizing the architecture on the application.
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 on a 3DNow machine, and branches to the appropriate code.
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 architecture 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
", htmlspecialchars("
ATI Rage 64MB
"), "
This makes it possible, for example, to report average or total
performance statistics for 3DNow hosts contrasted
with other Intel-compatible hosts.
Each BOINC project is free to create its own platforms. To avoid anarchy, however, we recommend that platform creation and naming be coordinated by a single group (currently the SETI@home project at UCB).
Platforms are maintained in the platform table in the BOINC DB, and can be created using the xadd utility. "; page_tail(); ?>