Changes between Version 203 and Version 204 of doc/FireFoxTorPerf

Jan 24, 2011, 7:03:35 PM (8 years ago)

replace the aged torrc options with the suggestion to use -alpha


  • doc/FireFoxTorPerf

    v203 v204  
    4646 * now we have circuit build time-outs occuring more frequently, we need to encourage Tor to try to generate circuits more often.
    4747 * Once we have established a circuit, we are assuming its a good one and we dont want it being timed out by firewalls or anything else. We need to make sure a ping occurs on the circuit to prevent this.
    48 Given this NFR, lets come up with some properties that may help satisfy it.
    50  * !CircuitBuildTimeout NUM
    51   . Try for at most NUM seconds when building circuits. If the circuit isn't open in that time, give up on it. (Default: 1 minute.) Force circuits that are quick to establish and thus likely to push traffic more quickly. Values as low as 2 seconds have been tried with good results, although this can cause severe damage to the Tor network if your network connection is simply not fast enough to establish any circuits in this time. The effect is a smaller 'Topological Radius' of servers used for Tor, ie the network connections available from your connection. Unfortunately, the smaller you make this number, the smaller the number of paths your client will use, and the less your anonymity.
    52   As of Tor v0.2.1.9-alpha, the CircuitBuildTimeout has been clipped to 30 seconds, which affects some of the tuning recommendations here. From the release notes:"
    53   ''Clip the CircuitBuildTimeout to a minimum of 30 seconds.
    54   Warn the user if lower values are given in the configuration.
    55   Bugfix on
    56 Patch by Sebastian.''"
    57  * !NumEntryGuards NUM
    58   . If we are going to be decreasing the CircuitBuildTimeout, you want to increase the likelihood you have a guard node fast enough to build these fast circuits for you. NUM=5 to 8 are good choices here.
    59  * !KeepalivePeriod NUM
    60   . To keep firewalls from expiring connections, send a padding keepalive cell every NUM seconds on open connections that are in use. If the connection has no open circuits, it will instead be closed after NUM seconds of idleness. (Default: 5 minutes)
    61  * !NewCircuitPeriod NUM
    62   . Every NUM seconds consider whether to build a new circuit. (Default: 30 seconds) Lets make Tor ready to establish a new circuit more readily.
    64 Settings that you may append to the end of the torrc configuration file are as follows:
    65 {{{
    66 # Try for at most NUM seconds when building circuits. If the circuit
    67 # isn't open in that time, give up on it.
    68 # (Default: 1 minute.)
    69 CircuitBuildTimeout 5
    71 # Increase the number of guards to increase the likelihood that
    72 # you will have a few guards fast enoiugh to build these circuits.
    73 # (Defaults to 3.)
    74 NumEntryGuards 6
    76 # Send a padding cell every N seconds to keep firewalls from closing
    77 # our connections while Tor is not in use.
    78 # (Default: 5 minutes)
    79 KeepalivePeriod 60
    81 # Force Tor to consider whether to build a new circuit every NUM
    82 # seconds.
    83 # (Default: 30 seconds)
    84 NewCircuitPeriod 15
    85 }}}
    87 As an added bonus, with these settings the "New Identity" button in Vidalia also effectively becomes a "This circuit is WAY too slow" button that you can mash to get a faster, more responsive circuit if Tor ever starts choking up on you. This is necessary because sometimes circuits will start out fast, but then get overloaded as traffic from other clients bursts and overwhelms the slowest node in the path.
     49In order to accomplish this, use the latest tor 0.2.2.x-alpha as circuit based timings are automatic and enabled by default.
    163125||DNS Cache || 36000(seconds (10 hours)) set in registry by hand, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters||
    165 == The proof is in the pudding, results ==
    166 With the changes made from Procedure 1 and 2, and a 2Mb connection, you can realise a sustained throughput of >100k, peaking at ~256k or more, with a ping response time of between 250 and 900ms. In other words, experimentation away from default settings, should enable you to saturate your internet connection (depending on Tor node capacity), which is the ideal result. All results tested under Tor v0.1.2.7-alpha(r17216)
    168 These figures were arrived at by using