From 23f97f631e47e3183d4084bacef38bc6de9e0919 Mon Sep 17 00:00:00 2001
From: warner <>
Date: Wed, 26 Sep 2007 22:07:00 +0000
Subject: [PATCH] add delay_rtt graph

[Imported from Trac: page Performance, version 9]
---
 Performance.md | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Performance.md b/Performance.md
index 920d881..195fb04 100644
--- a/Performance.md
+++ b/Performance.md
@@ -14,7 +14,7 @@ that). Uploading multiple files at once would increase this.
 
 ## Network Speed
 
-### test results
+### Test Results
 
 Using a 3-server testnet in colo and an uploading node at home (on a DSL line
 that gets about 78kBps upstream and has a 14ms ping time to colo) using
@@ -34,6 +34,13 @@ The munin
 [/tahoe-figleaf-graph/hanford.allmydata.com-tahoe_speedstats_delay.html delay graph] and
 [/tahoe-figleaf-graph/hanford.allmydata.com-tahoe_speedstats_rate.html rate graph] show these Ax+B numbers for a node in colo and a node behind a DSL line.
 
+The 
+[/tahoe-figleaf-graph/hanford.allmydata.com-tahoe_speedstats_delay_rtt.html delay*RTT graph] shows this per-file delay as a multiple of the average round-trip
+time between the client node and the testnet. Much of the work done to upload
+a file involves waiting for message to make a round-trip, so expressing the
+per-file delay in units of RTT helps to compare the observed performance
+against the predicted value.
+
 ### Roundtrips
 
 The 0.5.1 release requires about 9 roundtrips for each share it uploads. The