[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Ideas on increasing the significance of tor
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: Ideas on increasing the significance of tor
- From: "Michael_google gmail_Gersten" <keybounce@xxxxxxxxx>
- Date: Tue, 29 May 2007 11:04:58 -0700
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Tue, 29 May 2007 14:05:10 -0400
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lfHglCrOOlYATlRNuBiDDNHcVz7SALgZX2heClHLS1GCBV/R79KbnRa1l/kE+q+8RmiX52dA9AcgQgGyiTxdByPk7iFuu6+8KQzh4rs8qh4ZyG5VUMSCaHbATNcwBxNVrVp2stHx9kgOsX6iWw5M4yVWqxvQ9MuDB66tkdPIgBM=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=glEtEbF/9OjeAUi6Di8AGmS6MLm6ZJ6nmoyD8uD5tX4U4s6o5rCUJoDo3FK9MeRowPKhdbCi9Ua/fGeu1F5txcVZDKIIEIDVzFjEDpI5+Y0/+eMvhxZUjz8DQz79OwP44eHH3JPEds3q4jOalIDcql9xt9bv+qhDKaLDrnZsVa0=
- In-reply-to: <005601c7a122$4ee61510$4201a8c0@ROCKET>
- References: <005601c7a122$4ee61510$4201a8c0@ROCKET>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
Coming back to the matter of speed: what do we need to increase the
performance of the tor network? More tor (exit) nodes, right? (please
correct me if I'm wrong)
More nodes is not the answer. You could add one million dialup speed
nodes, and not improve the speed of Tor.
More bandwidth is part of the answer. One exit node with 21 gigawatts,
err, enough bandwidth might improve (possibly doubling) the speed of
Tor -- IF it has enough CPU power to run things.
I've seen circuits with only high-speed nodes (over 900 KB/s, as
reported by Vidallia) operate slowly (and the web server is fast as
soon as I switch Tor off). So bandwidth isn't the limit either.
The best I can conclude, from limited observations, is that CPU
overhead is critical. More connections are made to high bandwidth
nodes than they can handle (there is no "I'm full, I'm rejecting your
connection request" message in the Tor protocol that I know of).
The second limit is node speed. There's no way to say "Only use nodes
with at least <N> speed in my connections". As soon as I get a node
with less than 150 KB/s in my paths, my speed will be lower with Tor,
because that's my download speed.
The third limit is number of active connections. If I'm downloading a
file, I don't mind 20 KB/s paths *IF* I can use multiple paths. My
download manager is happy to work with 10 parts at once.
So, my suspicions:
1. An easy way to toggle between "At least speed X" (for
single-threaded web browsing) and "Any speed, many connections" (for
downloads).
2. A way to keep nodes from being CPU starved from the encryption
processing (high bandwidth nodes)
3. A way to keep nodes from being bandwidth starved (the main limit on
middle-speed nodes).