+6 FAQ entries

docs/en/faq.wml

@@ -132,12 +132,22 @@ country)
     </a></li>
     <li><a href="#WhyIsntMyRelayBeingUsedMore">Why isn't my relay being 
     used more?</a></li>
+    <li><a href="#IDontHaveAStaticIP">I don't have a static IP.</a></li>
+    <li><a href="#ModemKeepsCrashing">My cable/dsl modem keeps crashing. 
+    What's going on?</a></li>
+    <li><a href="#PortscannedMore">Why do I get portscanned more often 
+    when I run a Tor relay?</a></li>
+    <li><a href="#MoreThanOneCPU">I have more than one CPU. Does this 
+    help?</a></li>
     <li><a href="#HighCapacityConnection">How can I get Tor to fully 
     make use of my high capacity connection?</a></li>
     <li><a href="#RelayFlexible">How stable does my relay need to
 be?</a></li>
-    <li><a href="#ExitPolicies">I'd run a relay, but I don't want to
-deal
+    <li><a href="#BandwidthShaping">What bandwidth shaping options are 
+    available to Tor relays?</a></li>
+    <li><a href="#LimitTotalBandwidth">How can I limit the total amount 
+    of bandwidth used by my Tor relay?</a></li>
+    <li><a href="#ExitPolicies">I'd run a relay, but I don't want to deal
     with abuse issues.</a></li>
     <li><a href="#RelayOrBridge">Should I be a normal relay or bridge
     relay?</a></li>
@@ -1526,8 +1536,8 @@ it.)
 </p>
 
 <p>
-For other configuration options you can use, look at the <a href="<page
-docs/tor-manual>">Tor manual page</a>. Look at <a 
+For other configuration options you can use, see the <a href="<page
+docs/tor-manual>">Tor manual page</a>. Have a look at <a 
 href="https://gitweb.torproject.org/tor.git/blob/HEAD:/src/config/torrc.sample.in">
 the sample torrc file</a> for hints on common configurations. Remember, all 
 lines beginning with # in torrc are treated as comments and have no effect 
@@ -2031,6 +2041,82 @@ from the source code release tor-0.2.4.16-rc is:
     
     <hr>
 
+    <a id="IDontHaveAStaticIP"></a>
+    <h3><a class="anchor" href="#IDontHaveAStaticIP">I don't have a static 
+    IP.</a></h3>
+
+    <p>
+    Tor can handle relays with dynamic IP addresses just fine. Just leave 
+    the "Address" line in your torrc blank, and Tor will guess. 
+    </p>
+
+    <hr>
+
+    <a id="ModemKeepsCrashing"></a>
+    <h3><a class="anchor" href="#ModemKeepsCrashing">My cable/DSL modem 
+    keeps crashing. What's going on?</h3></a>
+
+    <p>
+    Tor relays hold many connections open at once. This is more intensive 
+    use than your cable modem (or other home router) would ever get normally. 
+    So if there are any bugs or instabilities, they might show up now. 
+    </p>
+    <p>
+    If your router keeps crashing, you've got two options. First, you should 
+    try to upgrade its firmware. If you need tips on how to do this, ask 
+    Google or your cable/router provider, or try the Tor IRC channel. 
+    </p>
+
+    <p>
+    Usually the firmware upgrade will fix it. If it doesn't, you will 
+    probably want to get a new (better) router. 
+    </p>
+
+    <hr>
+
+    <a id="PortscannedMore"></a>
+    <h3><a class="anchor" href="#PortscannedMore">Why do I get portscanned 
+    more often when I run a Tor relay?</a></h3>
+
+    <p>
+    If you allow exit connections, some services that people connect to 
+    from your relay will connect back to collect more information about you. 
+    For example, some IRC servers connect back to your identd port to record 
+    which user made the connection. (This doesn't really work for them, 
+    because Tor doesn't know this information, but they try anyway.) Also, 
+    users exiting from you might attract the attention of other users on the 
+    IRC server, website, etc. who want to know more about the host they're 
+    relaying through. 
+    </p>
+    <p>
+    Another reason is that groups who scan for open proxies on the Internet 
+    have learned that sometimes Tor relays expose their socks port to the 
+    world. We recommend that you bind your socksport to local networks only. 
+    </p>
+    <p>
+    In any case, you need to keep up to date with your security. See this <a 
+    href="https://trac.torproject.org/projects/tor/wiki/doc/OperationalSecurity">article 
+    on operational security for Tor relays</a> for more suggestions. 
+    </p>
+
+    <hr>
+
+    <a id="MoreThanOneCPU"></a>
+    <h3><a class="anchor" href="#MoreThanOneCPU">I have more than one CPU. 
+    Does this help?</a></h3>
+
+    <p>
+    Yes. You can set your NumCpus config option in torrc to the number of 
+    CPUs you have, and Tor will spawn this many cpuworkers to deal with 
+    public key operations in parallel. 
+    </p>
+
+    <p>
+    This option has no effect for clients. 
+    </p>
+
+    <hr>
+
     <a id="HighCapacityConnection"></a>    
     <h3><a class="anchor" href="#HighCapacityConnection">How can I get Tor to fully 
     make use of my high capacity connection?</a></h3>
@@ -2093,6 +2179,114 @@ too.
     </ul>
 
     <hr>
+    
+    <a id="BandwidthShaping"></a>
+    <h3><a class="anchor" href="#BandwidthShaping">What bandwidth shaping 
+    options are available to Tor relays?</a></h3>
+
+    <p>
+    There are two options you can add to your torrc file: 
+    </p>
+    <ul>
+    <li>
+    BandwidthRate is the maximum long-term bandwidth allowed (bytes per 
+    second). For example, you might want to choose "BandwidthRate 2 MB" 
+    for 2 megabytes per second (a fast connection), or "BandwidthRate 50 
+    KB" for 50 kilobytes per second (a medium-speed cable connection). 
+    The minimum BandwidthRate is 20 kilobytes per second. 
+    </li>
+    <li>
+    BandwidthBurst is a pool of bytes used to fulfill requests during 
+    short periods of traffic above BandwidthRate but still keeps the 
+    average over a long period to BandwidthRate. A low Rate but a high 
+    Burst enforces a long-term average while still allowing more traffic 
+    during peak times if the average hasn't been reached lately. For example, 
+    if you choose "BandwidthBurst 50 KB" and also use that for your 
+    BandwidthRate, then you will never use more than 50 kilobytes per second; 
+    but if you choose a higher BandwidthBurst (like 1 MB), it will allow 
+    more bytes through until the pool is empty.
+    </li>
+    </ul>
+    <p>
+    If you have an asymmetric connection (upload less than download) such 
+    as a cable modem, you should set BandwidthRate to less than your smaller 
+    bandwidth (Usually that's the upload bandwidth). (Otherwise, you could 
+    drop many packets during periods of maximum bandwidth usage -- you may 
+    need to experiment with which values make your connection comfortable.) 
+    Then set BandwidthBurst to the same as BandwidthRate. 
+    </p>
+    <p>
+    Linux-based Tor nodes have another option at their disposal: they can 
+    prioritize Tor traffic below other traffic on their machine, so that 
+    their own personal traffic is not impacted by Tor load. A ​<a 
+    href="https://gitweb.torproject.org/tor.git/blob/HEAD:/contrib/linux-tor-prio.sh">script
+    to do this</a> can be found in the Tor source distribution's contrib 
+    directory. 
+    </p>
+    <p>
+    Additionally, there are hibernation options where you can tell Tor to 
+    only serve a certain amount of bandwidth per time period (such as 100 
+    GB per month). These are covered in the <a 
+    href="#LimitTotalBandwidth">hibernation entry</a> below. 
+    </p>
+    <p>
+    Note that BandwidthRate and BandwidthBurst are in <b>Bytes,</b>not Bits. 
+    </p>
+
+    <hr>
+
+    <a id="LimitTotalBandwidth"></a>
+    <h3><a class="anchor" href="#LimitTotalBandwidth">How can I limit the 
+    total amount of bandwidth used by my Tor relay?</a></h3>
+    <p>
+    The accounting options in the torrc file allow you to specify the maximum 
+    amount of bytes your relay uses for a time period. 
+    </p>
+    <pre>
+    AccountingStart day week month [day] HH:MM
+    </pre>
+    <p>
+    This specifies when the accounting should reset. For instance, to setup 
+    a total amount of bytes served for a week (that resets every Wednesday 
+    at 10:00am), you would use: 
+    </p>
+    <pre>
+    AccountingStart week 3 10:00
+    AccountingMax N bytes KB MB GB TB
+    </pre>
+    <p>
+    This specifies the maximum amount of data your relay will send during an 
+    accounting period, and the maximum amount of data your relay will receive 
+    during an account period. When the accounting period resets (from 
+    AccountingStart), then the counters for AccountingMax are reset to 0.
+    </p>
+    <p>
+    Example. Let's say you want to allow 1 GB of traffic every day in each 
+    direction and the accounting should reset at noon each day: 
+    </p>
+    <pre>
+    AccountingStart day 12:00
+    AccountingMax 1 GB
+    </pre>
+    <p>
+    Note that your relay won't wake up exactly at the beginning of each 
+    accounting period. It will keep track of how quickly it used its 
+    quota in the last period, and choose a random point in the new interval 
+    to wake up. This way we avoid having hundreds of relays working at the 
+    beginning of each month but none still up by the end. 
+    </p>
+    <p>
+    If you have only a small amount of bandwidth to donate compared to your 
+    connection speed, we recommend you use daily accounting, so you don't 
+    end up using your entire monthly quota in the first day. Just divide 
+    your monthly amount by 30. You might also consider rate limiting to 
+    spread your usefulness over more of the day: if you want to offer X GB 
+    in each direction, you could set your BandwidthRate to 20*X. For example, 
+    if you have 10 GB to offer each way, you might set your BandwidthRate to 
+    200 KB: this way your relay will always be useful for at least half of 
+    each day. 
+    </p>
+    <hr>
 
     <a id="ExitPolicies"></a>
     <h3><a class="anchor" href="#ExitPolicies">I'd run a relay, but I