torproject/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-12-06 19:41:15 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

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

Browse Source 
svn:r1035
This commit is contained in:
Nick Mathewson
2004-01-31 01:45:16 +00:00
parent f00dc6fe1e
commit 4c74717564
1 changed files with 16 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/tor-design.tex
+16 -12
View File
@@ -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.