|
|
@@ -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.
|
Roger Dingledine