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