]> git.ipfire.org Git - thirdparty/tor.git/commitdiff
put the right numbers in
authorRoger Dingledine <arma@torproject.org>
Mon, 2 Feb 2004 06:13:04 +0000 (06:13 +0000)
committerRoger Dingledine <arma@torproject.org>
Mon, 2 Feb 2004 06:13:04 +0000 (06:13 +0000)
i'll leave the other phrasing for nick

svn:r1052

doc/tor-design.tex

index 57920de22fea192a0bd03dfd40ca5b2a0d827c3e..f598d396501b30cb70fc822aa0cfc0074d0003e9 100644 (file)
@@ -1575,9 +1575,9 @@ 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
+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
 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