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 d53faf48f19b37896d0c5743d4b60586e528dd12 (commit) from c8ed620bc499563fa0a5dbd472a7ba0da9eda304 (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 d53faf48f19b37896d0c5743d4b60586e528dd12 Author: Phil Carns <[email protected]> Date: Mon Oct 29 15:11:29 2012 -0400 edit description of triton model ----------------------------------------------------------------------- Summary of changes: .../simulation-2012-10/simulation-2012-10.txt | 40 ++++++++++--------- 1 files changed, 21 insertions(+), 19 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 4d0b52c..e45d1be 100644 --- a/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt +++ b/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt @@ -164,20 +164,21 @@ well. === Simulation -n this report we focus on the activities -that servers perform following a failure and therefore do not model client -processes or applications. The key components of the Triton ROSS model are -therefore the the network devices, disk devices, and storage protocols used -by the servers. +We have constructed a discrete event simulator for the Triton storage system in +order to evaluate its rebuild performance at scale. The model does not yet +include client processes or application workloads. It instead focuses on +the behavior of servers as they recovery from fault conditions. The key +components of the model are the network devices, disk devices, and storage +protocols used by the servers. The network model is a simple cost model based on the startup cost (latency) of the network and the bandwidth (cost per byte transferred) of the network. Each server is assumed to have full-duplex transmit -and receive capability. Messages begin transmission when the sender -has output queue availability and appear to complete from the sender's -perspective as soon as the startup and bandwidth costs have been computed. -However, the message is not delivered for processing on the receiving -side until the receiver's input queue is available.The network fabric +and receive capability. Messages begin transmission when the sender's +output queue is available. From the sender's perspective, the transmission +is complete as soon as enough virtual time has elapsed to account for the +startup and bandwidth costs of the message. +However, the message is not delivered for processing on the receiver until the receiver's input queue is also available. The network fabric itself is not modeled and is instead treated as if it has infinite buffering ability and no internal routing overhead. @@ -189,8 +190,8 @@ The storage protocol used by Triton uses a "pull" model in which rebuilding servers request data from surviving replicas until they have reconstructed all necessary replicas. Each data transfer includes both a request and acknowledgment in addition to the actual data payload itself. Requests and -acknowledgments will be transmitted using traditional two-sided messages, -while the data payload will be transmitted using one-sided RDMA put +acknowledgments are transmitted using traditional two-sided messages, +while the data payload is transmitted using one-sided RDMA put operations. @@ -229,19 +230,20 @@ digraph triton_sim { <<fig-triton-sim>> illustrates the steps involved in transferring a single data buffer between two servers during the rebuild process. -We assume that the rebuilding server (shown in red nodes) begins with -complete knowledge of which objects must be transferred. The nodes shown -in blue represent steps carried out on the server that is responding -to a rebuild request. The buffer in question is read from disk on +We assume that the rebuilding server begins with +complete knowledge of which objects must be transferred. The steps carried +out by the rebuilding +server are shown in red and the steps carried out by the responding server +are shown in blue. +The data buffer is read from disk on the responding server and written to disk on the rebuilding server. -As described earlier, each transfer requires three messages: a request, +As described earlier, each transfer requires three network messages: a request, a buffer (payload) transfer, and a response. The rebuilding server cannot -write to disk until it has received both the data buffer and the response. +write the buffer to disk until it has received both the data buffer and the response. Each server limits the total amount of memory used for sending and receiving data payloads in order to insure that servers are not overwhelmed by incoming data messages. - For clarity, the <<fig-triton-sim>> does not show pipelining. In practice, however, servers will issue multiple overlapping requests as long as memory buffers are available and the disk and network bandwidth are hooks/post-receive --