[or-cvs] Rewrite performance results paragraph, using moria->moria->...

[Nick Mathewson]

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/tmp/cvs-serv5566

Modified Files:
	tor-design.tex 
Log Message:
Rewrite performance results paragraph, using moria->moria->network results and new #s from arma

Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.142
retrieving revision 1.143
diff -u -d -r1.142 -r1.143
--- tor-design.tex	30 Jan 2004 15:06:59 -0000	1.142
+++ tor-design.tex	31 Jan 2004 01:45:16 -0000	1.143
@@ -1541,18 +1541,22 @@
 %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.