chicken out and revert to previous test results.

this is the final version.

svn:r1056

diff --git a/doc/tor-design.tex b/doc/tor-design.tex
index 673fdf356150b135216a645764cdc81d57e24ab9..5a7cc2520d0494706ea620eba8698deb71a97e43 100644 (file)
--- a/doc/tor-design.tex
+++ b/doc/tor-design.tex
@@ -1574,15 +1574,19 @@ 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) every 10 minutes for
-21.3 hours (128 sample points): while a direct
+fetching the front page of {\tt cnn.com} (55 kilobytes): %every 10 minutes for
+%26 hours (156 sample points):
+while a direct
 download consistently took about 0.3s, the performance through Tor was highly
-variable. Some downloads were as fast as 0.3s, with a median at 2.6s, and
-90\% finishing within 6.0s.  It seems that as the network expands, the chance
+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.
+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.