| | 1 | = BOINC client simulator = |
| | 2 | |
| | 3 | The BOINC client simulator simulates the CPU scheduling and work-fetch policies of the BOINC client. It uses the same source code as the core client for these policies. The simulator can be built with 'makefile_sim' on Unix or the 'sim' project on Windows. |
| | 4 | == Usage == |
| | 5 | |
| | 6 | {{{ |
| | 7 | sim [--duration X] [--delta X] [--dirs d1 ...] |
| | 8 | }}} |
| | 9 | runs the simulator with the given duration and time step. When run with --dirs, chdirs into each of the given directories, and runs a simulation based on the input files there. Prints summaries of each one separately, and a total summary. |
| | 10 | |
| | 11 | |
| | 12 | == Output files == |
| | 13 | The simulator creates two output files: '''sim_log.txt''': This is the message log (same as would be generated by the client). Its contents are controlled by cc_config.xml. '''sim_out.html''': When viewed in a web browser, a 'time line' showing what's running when. |
| | 14 | |
| | 15 | |
| | 16 | == Input files == |
| | 17 | The input consists of four files. |
| | 18 | === sim_projects.xml === |
| | 19 | This describes a set of attached projects. |
| | 20 | {{{ |
| | 21 | <projects> |
| | 22 | <project> |
| | 23 | <project_name>P1</project_name> |
| | 24 | <resource_share>100</resource_share> |
| | 25 | <app> |
| | 26 | <latency_bound>1000</latency_bound> |
| | 27 | <fpops_est>1e9</fpops_est> |
| | 28 | <fpops> |
| | 29 | <mean>1e9</mean> |
| | 30 | <stdev>1e5</stdev> |
| | 31 | </fpops> |
| | 32 | <working_set>100000000</working_set> |
| | 33 | </app> |
| | 34 | ... |
| | 35 | <available> |
| | 36 | <frac>.7</frac> |
| | 37 | <lambda>1000</lambda> |
| | 38 | </available> |
| | 39 | </project> |
| | 40 | ... |
| | 41 | </projects> |
| | 42 | }}} |
| | 43 | A project has one or more applications. Each application has a given latency bound and working-set size. The number of FP ops is a truncated normal distribution with the given mean and standard deviation. The availability of the projects (i.e. the periods when scheduler RPCs succeed) is modeled with two parameters: the duration of available periods are exponentially distributed with the given mean, and the unavailable periods are exponentially distributed achieving the given available fraction. |
| | 44 | |
| | 45 | |
| | 46 | === sim_host.xml === |
| | 47 | This describes the host hardware and availability. |
| | 48 | {{{ |
| | 49 | <host> |
| | 50 | <p_fpops>x</p_fpops> |
| | 51 | <m_nbytes>x</m_nbytes> |
| | 52 | <p_ncpus>x</p_ncpus> |
| | 53 | <available> |
| | 54 | <frac>.7</frac> |
| | 55 | <lambda>1000</lambda> |
| | 56 | </available> |
| | 57 | <idle> |
| | 58 | <frac>.7</frac> |
| | 59 | <lambda>1000</lambda> |
| | 60 | </idle> |
| | 61 | </host> |
| | 62 | }}} |
| | 63 | The available periods (i.e., when BOINC is running) and the idle periods (i.e. when there is no user input) are modeled as above. |
| | 64 | === sim_prefs.xml === |
| | 65 | Same format as the global_prefs.xml file. |
| | 66 | === cc_config.xml === |
| | 67 | Same format as the client's cc_config.xml file. |
