This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "". The branch, master has been updated via c0d5ed5d81bf93805a3e9341b922dad2806df65f (commit) from bbd5d84250663d4a8ffb2db641519014f59be834 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit c0d5ed5d81bf93805a3e9341b922dad2806df65f Author: Phil Carns <[email protected]> Date: Mon Oct 29 13:38:03 2012 -0400 edit abstract ----------------------------------------------------------------------- Summary of changes: .../simulation-2012-10/simulation-2012-10.txt | 28 +++++++++++-------- 1 files changed, 16 insertions(+), 12 deletions(-) Diff of changes: diff --git a/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt b/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt index dfdfa92..76abc51 100644 --- a/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt +++ b/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt @@ -4,21 +4,25 @@ Triton: Resilient Storage Simulation [abstract] == Abstract -Simulation is a critical component of long-range exascale architecture -evaluation. It offers the ability to explore design space trade offs -well in advance of hardware availability and evaluate -complex algorithms that may be difficult to capture adequately with analytical -models. One example of a design space domain that is well-suited to -simulation is the mechanism used by the storage system to reconstruct data -following a server failure. The goal of a reconstruction +Simulation is a critical tool for evaluation of exascale architectures. +It offers the ability to explore design space trade offs before hardware +availability and evaluate complex algorithms that are difficult to +capture with analytical models. The reconstruction algorithm used by the +storage system to recover from faults is an example of an exascale design +space that is well-suited to simulation techniques. +The goal of a reconstruction algorithm should be to recover data quickly enough to avoid data loss from subsequent failures while minimizing the impact on application I/O -performance. Unfortunately, reconstruction time is impacted by a variety -of factors ranging from architecture parameters (disk speed, network +performance. This type of algorithm is difficult to evaluate through +prototyping because it would require exclusive access to a large, fully populated +storage system. It is also difficult to evaluate through analytical models +due to the range of parameters that may affect performance. +Reconstruction time is impacted by a variety +of factors ranging from architecture parameters (e.g., disk speed, network speed, number of servers, expected failure rate), system characteristics -(number of objects, distribution of object sizes, replication factors), -and software algorithms (replica placement strategies, pipelining). -In this report we show preliminary results from a parallel discrete event +(e.g., number of objects, distribution of object sizes, replication levels), +and software algorithms (e.g., replica placement strategies, pipelining). +In this report we present preliminary results from a parallel discrete event simulation of object reconstruction time in the Triton storage system. These results demonstrate our ability to simulate system performance at scales larger than can be effectively tested on existing systems. hooks/post-receive --