Rewrite performance results paragraph, using moria->moria->network results and new #s from arma

svn:r1035

1 files changed, 16 insertions, 12 deletions

diff --git a/doc/tor-design.tex b/doc/tor-design.tex
index af9d96da7e..f931bb95af 100644
--- a/doc/tor-design.tex
+++ b/doc/tor-design.tex
@@ -1541,18 +1541,22 @@ performance. % Right now the first $500 \times 500\mbox{B}=250\mbox{KB}$
 %of the stream arrives
 %quickly, and after that throughput depends on the rate that \emph{relay
 %sendme} acknowledgments arrive.
-For example, we did some informal tests using a test network of 4 nodes on
-the same machine. We downloaded a 60 megabyte file from {\tt debian.org}
-every 30 minutes for 2 days (100 sample points). It arrived in about
-300 seconds on average, compared to 210s for a direct download. We ran
-the same test on the main Tor network, pulling down the front page of
-{\tt cnn.com}: while a direct download consistently took about 0.5s,
-the performance through Tor was highly variable. Some downloads were
-as fast as 0.6s, with others as slow as 25s (the average was 2.5s). It
-seems that as the network expands, the chance of getting a slow circuit
-(one that includes a slow or heavily loaded Tor node) is increasing. On
-the other hand, we still have users, so this performance is good enough
-for now.
+To quantify these effects, we did some informal tests using a network of 4
+nodes on the same machine (a heavily loaded 1GHz Athlon). We downloaded a 60
+megabyte file from {\tt debian.org} every 30 minutes for 54 hours (108 sample
+points). It arrived in about 300 seconds on average, compared to 210s for a
+direct download. We ran a similar test on the production Tor network,
+fetching the front page of {\tt cnn.com} (55 kilobytes): while a direct
+download consistently took about 0.5s, the performance through Tor was highly
+variable. Some downloads were as fast as 0.6s, with a median at 2.7s, and
+80\% finishing within 5.7s.  It seems that as the network expands, the chance
+of building a slow circuit (one that includes a slow or heavily loaded node
+or link) is increasing.  On the other hand, as our users remain satisfied
+with this increased latency, we can address our performance incrementally as we
+proceed with development.\footnote{For example, we have just begun pushing
+  a pipelining patch to the production network that seems to
+  decrease latency for medium-to-large files; we will present revised
+  benchmarks as they become available.}
 
 %With the current network's topology and load, users can typically get 1-2
 %megabits sustained transfer rate, which is good enough for now.