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 135ed2da21182dd77a58c77b59dc9a66cf898141 (commit) from c0ba5873ed94bf412416f0aa96b40304132b5cf0 (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 135ed2da21182dd77a58c77b59dc9a66cf898141 Author: Phil Carns <[email protected]> Date: Mon Oct 29 10:24:11 2012 -0400 clean up abstract some ----------------------------------------------------------------------- Summary of changes: .../simulation-2012-10/simulation-2012-10.txt | 38 ++++++++++--------- 1 files changed, 20 insertions(+), 18 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 d5caa87..4752460 100644 --- a/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt +++ b/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt @@ -4,25 +4,27 @@ Triton: Resilient Storage Simulation [abstract] == Abstract -Simulation is an key tool for long-term exascale architecture evaluation -because of x, y, z (allows us to explore design space before hardware -exists, can rapidly try out algorithms without prototyping, etc. etc.). -Storage system reconstruction algorithms are one example of a design space -that is well suited to simulation. The goal of a reconstruction algorithm -should be to reconstruct data quickly enough to avoid data loss from -subsequent failures while minimizing the impact on application I/O +Simulation is a critical component of long-range exascale architecture +evaluation. It offers the ability to explore design space tradeoffs +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 +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 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 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. In future work we will utilize this -simulation framework in conjunction with projected system parameters to -guide and validate key algorithmic choices in the Triton prototype -implementation. +of factors ranging from architecture parameters (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 +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. +In future work we will utilize this simulation framework in conjunction +with projected system parameters to guide and validate key algorithmic +choices in the Triton prototype implementation. == Introduction hooks/post-receive --